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

И так вернемся к проблеме. Ах прости, а в чем собственно проблема? Да надо сначала поведать о теме беседы и ее результатах.
Хотя внимательный читатель естественно понял тему беседы, но он жаждет узнать, а каковы ее результаты.

Итак некая компания Х в городе Н занимается производством КИС. Проект возник как ответ на веления времени и был реализован на одном из предприятий страны С. Мало по малу другие компании и организации страны С стали интересоваться КИС. Это так сказать предыстория.

Беседа эе с коллекгами заключалась в том, что можно и нужно ли использовать UML в проектировании КИС, и если да, то как это возможно.
Мои оппоненты весьма не глупые люди с богатым опытом программирования и работы в разных ИТ-компаниях, высказали мысль, что UML и многие другие методики и языки моделирования - все это красивая игрушка для пускания пыли в глаза заказчику, не более.
Мотивация. КИС - сложная система с огромным количеством классов и связей между ними. Как можно представить даже часть такой системы в виде ДК и как отобразить все многообразией связей, которые возникают между объектами. Т.е. мысль такая - при реализации ДК даже небольшой части системы мы получим такую огромную диаграмму с такми количеством связей, что вся ее изобразительная значимость, ее информативность окажется бесполезной. И потом - зачем тратить огромное, гигантское количество времени на подготовку ДК, чтобы в будущем в общем никак ею не воспользоваться. При этом надо ее постоянно сопровождать, обновлять, если происходят изменения кода и т.д. и т.п.
Была высказана мысль, что время, которое потратит человек на создание такой модели существенно больше, чем он бы потратил на простое кодирование. Митивация: грамотный человек умеет строить код и без предварительного моделирования, а не грамотный - ну нам такие не нужны... Проводится мысль - может UML и неплохо, но для его овладения нужно много времени и средств, а его преподавания не поставлено на такую основу, как скажем химия, математика, физика, бухгалтерский учет и т.п. Поэтому - использование UML бессмысленно, бесполезно и даже вредно.
В их рассуждениях я заметил одну неточность на мой взгляд. Мои коллеги путают язык UML и процесс проектирования и кодирования(реализации). Я высказал мысль, что просто в компании нет грамотного процесса производства, не отработана его технологичность, а возможно просто пока вы либо не доросли до этого, либо в данной ситуации это вам не подходит - маленький коллектив - смешение ролей, когда программист является и системным аналитиком и проектировщиком и кодером и тестировщиком, а порой и внедренцем.

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

Ну могу добавить что:
1. У нас в компании UML не применим в полном объеме, не оправдает его использование себя.
2. В софтверных конторах с зарубежными основателями весь процесс разработки расписан, раздроблен и жестоко контролируется. Там каждый выполняет свою роль и если не единственно то весьма полезное средство общения это UML.
Так что пример про завод это только единичный случай и пример нашего менеджмента производственного процесса.
ИМХО часто западный менеджмент намного превосходит наш.

вопрос:
А действительно кто-то использует UML грамотно и хорошо и на всех стадиях проекта, причем проекта очень больших и сложных систем? Или UML все-таки инструмент обучения, возможно инструмент бизнес-аналитиков, и возможно рассчитан на небольшие, обозримые проекты...

А что будет делать начальник производства когда 1-2 человека уйдет из его процесса?
Как он будет работать дальше? Как введет в курс дела людей?
Все должно быть формализовано на большом долго-играющем производственном процессе.
Иначе при потере кадров или мотивации будет хаос. Иначе человек скажет "не понимаю" сделает как он это видит и привык, новые работники будут долго въезжать "в общение".
Вариант формализация при помощи UML (типа RUP).

Раньше обходились без UML? -да, формализовали процесс все? - нет.
Значит вопрос в том лучше ли ЮМЛ старого способа формализации.
Думаю да, + он всетаки претендует на Unified
Оправдан ли на него переход? думаю не всегда, с нашей организацией производства далеко не всегда.

Полностью согласен с предыдущими ораторами.
В общем, ЮМЛ - это только одно из средств формализации. Можно формализировать разными способами: текст, картинки, IDEF, ну и на конец ЮМЛ. Не важно как, но надо. Сам был програмистом и помню тот момент, когда к концу проекта не помнишь, что было в начале и помагали только - требования. Бусть они будут бизнес/системные или просто в вольной форме. Но они очень помогают при реинжиниринге. А вот насколько они помогают - это уже тема дисера.

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

Странно куда-то исчез пост.

Ну да ладно.

Лучше тогда рассмотреть вопрос, когда это удобно, когда нет и при каких еще дополнительных условиях...

you are welcome, прошу высказываться за и против

А вот насколько они помогают - это уже тема дисера.

на докторскую потянет? А то можно занятся:-))

Вопрос того, что UML обременителен, и нужно тратить время на поддержание моделей происходит от использования UML не с той стороны :-). Если мы начинаем с того, что выделяем в системе три слоя -- GUI, Бизнес-логики и слой работы с данными, то использование UML очень даже оправдано при проектировании последних двух. Естественно при наличии Domain model. А если КИС или другое ПО сделано в стиле "спагетти", когда бизнес-логика рзамазана по GUI и хранимым процедурам в БД ... то UML тут НИКАК не поможет ... тут уже ничего не поможет :-).
Процесс внесения изменений начинается с изменения модели, и анализа влияния изменений. Можно оперировать на уровне интерфесов классов добавляя методы например, или вводя новые классы при изменении бизнес-сущностей.  Более того, можно использовать UML только для ядра системы или для поддержки фреймворка, заложенного в систесму, почему нет? Для больших систем -- управлять на уровне пакетов. Другой вопрос, что приходится проектировать пакеты так, чтобы они не пересекались по данным ... а это уже вопрос в т.ч. и квалификации проектировщика (вне зависимости от того знает от UML или нет).

У меня такая проблема была, когда я пришел в компанию там писалась система управления контентом сайта (КМС). Человек который ее писал был ярым противником не то что проектирования, а вообще любого планирования, в общем очень «креативная» личность. Мне пришлось брать то, что было и в бешеном темпе подгонять под минимальную работоспособность, чтоб ставить это все на сайты клиентов.
Когда агония сдачи проектов прошла, было принято решение вносить новую функциональность и вообще перестраивать систему. Как оказалось разобраться в хаотически перемешанном коде не очень просто и тогда мне любезно позволили сделать архитектуру этой системы. До этого я все уши прожужжал, что без определенной архитектуры эта система просто не сможет дальше развиваться. И вот, наконец появилась возможность как-то это все упорядочить, и я вдруг осознал, что не владею каким бы то ни было серьезным инструментом для решения подобной задачи. Вопрос к вам уважаемые форумчане поможет ли мне UML, если нет то что использовать в такой ситуации и вообще какие есть эффективные и простые инструменты для проектирования программных систем среднего размера.

На мой не искушенный взгляд - поможет, поможет все, чем можно формализовать. Главное, чтобы то, что вы рисуете, изображаете и формализуете, было также понятно окружающим. Постулируя тот факт, что на сегодняшний момент - это UML, IDEF и т.п., то следует идти от них.

Далее нужно понять, система будет строится с использованием классов и объектов или чисто в структурном подходе. В первом случае, конечно, имеет смылс разобраться с UML и всем что с ним связано, во втором- вероятно стоит использовать DFD, т.к. он ориентирован на процедурно- функциональный подход.

Чаще всего CMS(content managment system) реализуются в смещанном подходе. Но и тогда UML может быть полезным.

Например инструмент ArgoUML, как заявлено может быть сориентирован на РНР с генерацией схемы.

С другой стороны - при построении CMS, в первую очередь реализуют информационную архитектуру сайта. Например на сайтах joom.ru или joomlaportal.ru можно найти документ API Joomla

Я думаю, что UML не всегда подходит для описания системы. Например, контора пишет SRS к очередному продукту для заказчика. Но так как заказчик в полной мере не владеет UML, то приходится использовать лишь интуитивно-понятные графические элементы, да и те сопровождать/дублировать текстовым описанием. Если бы, к примеру, все знали UML, также как все умеют читать или знают таблицу умножения, то его использование было бы более повсеместно.

Я думаю, что UML не всегда подходит для описания системы. Например, контора пишет SRS к очередному продукту для заказчика. Но так как заказчик в полной мере не владеет UML, то приходится использовать лишь интуитивно-понятные графические элементы, да и те сопровождать/дублировать текстовым описанием. Если бы, к примеру, все знали UML, также как все умеют читать или знают таблицу умножения, то его использование было бы более повсеместно.

Забавно ... но если речь идет о разработке требований к системе, которые как раз и описываются в документе SRS, то зачем там нужен UML??? В большей степени UML адекватен именно при проектировании, а не при описании требований причем при определенных условиях -- о чем я писал ранее. Лично я очень редко использую UML, даже для иллюстрации требований. Ну может только если какую-нить activity диаграмму ... для описания некоего сценария ... А что касается документов, описывающих архитектуру и дизайн, то очень редко когда возникает необходимость их обсуждения с неспециалистами в ИТ ...

Юра, Ну ты уж так не пугай народ.
Чтобы сформулировать пользовательские требования можно использовать ДВИ, ДД, ДС, ДП. Так же можно построить структурную концептуальную модель на ДК. Но полноценно описать требования не получится - текст и еще раз текст.

Не имел цели напугать :-) ... но "тем не более", формально, классический SRS по IEEE 830 ничего про пользовательские требования не говорит. Тот же Вигерс их размещает в отельном документе. Я не спорю вполне можно "нарисовать" юзкейсы и дополнить их диаграммами описывающими динамику (те же activity). Но ты совершенно справедиво заметил, что этого не всегда достаточно. Несомненно в ряде проектов я просто не писал потробные и "формальные" требования -- особенно если я сам же и выступал разработчиком такого ПО, в лучшем случае основные фичи с заказчиком согласовывал, а дальше прототипами подгонялось под идеал :-).

Лично в нашей команде UML нужен для того, чтобы коротко, просто и наглядно сформулировать, как всё должно быть, а потом не забыть этой формулировки. Сформулировать последовательно, на разных уровнях - от "какую цель преследует система" до "как мы будем использовать декоратор, чтобы представить A для В как С". Причём сформулировать ДО того, как сделать. Ну и для того, чтобы знать, например, что: "Ага, изменилась цель (ограничение, UC) A - значит, изменятся алгоритмы (activity) B и C, и объекты Q, W, E, R, T, Y".

Добрый день всем! А как вы считаете для формализации деяетельности компании хорошо подходит UMl? Т.е. в итоге мы хотим получить просто формализацию процессов деятельности

Имхо: не очень хорошо подходит. Так как заточен под проектирование, а не под описание процессов. А вот BPMN или нотация, используемая в ARIS'е (по-моему), создавались именно для описания процессов/деятельности компании. Т.о. если процессы потом не будут автоматизироваться проектируемой ИС, нет смысла выбирать именно UML в качестве нотации.

Добрый день всем! А как вы считаете для формализации деяетельности компании хорошо подходит UMl? Т.е. в итоге мы хотим получить просто формализацию процессов деятельности

Довольно интересное решение дает компания Telelogic со своей линейкой ПО. В частности System Architect позволяет использовать разные нотации для моделировани процессов предприятия, в то числе и интегрировать UML для этой задачи. Другое дело, что продукт довольно дорогой...