F>>Что господа программисты могут сказать о целесообразности изучения сабжа?
M.NET>>Абсолютно безполезно, только время зря тратить :)

Все зависит от того чем ты собираешься заниматься.

Если собираешься рубать на конвеере ширпотреб, где в общем все модели известны (хотя, может, и не описаны), напр. небольшие справочные системы, автоматизатия бухгалтеркой д. :), "корпоративные сайты" (в кавычках, надеюсь, понимаете что я имею в виду :) и пр., слонов, короче, всю программерскую жизнь ловить, то UML не просто бесполезен, он просто вреден, потомучто заставляет задумываться над тем что ты делаешь и правильно ли ты это делаешь, что в таком деле отнимает слишком много времени, так как в этом деле лучше сделать три плохонько спроектированные проги (все равно заплатят — никуда не денуться), чем одно хорошую, но долго.

Если же надеешься хоть когда-то заняться серьезными вещами, промышленными решениями автоматизации, крупными и сверх крупными информационными системами, програмным обеспечением научно-исследоваательской деятельности. То UML (или что-то подобное, коего море) — это must have, иначе выкинуть тя нахер от туда, там программеры не нужны, нужны только иженеры (умеющие, например, программить :).

А также зависит от того, что ты считаешь (_для себя_) продуктом "разработки програмного обеспечения" (РПО :).

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

А вот я напр. не считаю (для себя) код продуктом РПО. Вот для заказчика, да код — это продукт, он его покупает (думает, что покупает решение, а на самом деле покупает код :). А для меня код — мусор, благо он уже продан, и у меня его какбы уже и нету. А вот xp'ы набранные в процессе _проектирования_ системы, части построенных моделей — вот это то, что останется у меня, то что мое. И именно это я смогу использовать в других системах. Я вообще скептически отношусь к code reuse, что касается кода проблемной области, потому что он обычно отличается в той степени, в какой отличаются и проблемные области (вопрос о конвеере и почему там так не происходит), и тащить код из одной проблемной области в др можно, как можно писать проги в машинных кодах (а кто говорит, что нельзя?), но полученное решение будет не таким, что можно сказать, лет через 10 — _Я_ это сделал. А вот наработанные части моделей таскать вполне резонно.

Мое мнение — незнание UML (или, опять же, другого подобного инструмента), значит привязывать себя к одному языку программирования (ведь именно там остануться все наработки, если (вернее, когла) придется пересесть на другой.

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

Thus, ruki proch ot UML, что в переводе с пуэрториканского означает, что знание UML — важно :)]

Здравствуйте Frostbitten, Вы писали:

F>Все зависит от того чем ты собираешься заниматься.
F>Если собираешься рубать на конвеере ширпотреб, где в общем все модели известны (хотя, может, и не описаны), напр. небольшие справочные системы, автоматизатия бухгалтеркой д. , "корпоративные сайты" (в кавычках, надеюсь, понимаете что я имею в виду и пр., слонов, короче, всю программерскую жизнь ловить, то UML не просто бесполезен, он просто вреден, потомучто заставляет задумываться над тем что ты делаешь и правильно ли ты это делаешь, что в таком деле отнимает слишком много времени, так как в этом деле лучше сделать три плохонько спроектированные проги (все равно заплатят — никуда не денуться), чем одно хорошую, но долго.

Вся экономика Запада построена на идее "good enough" ПО. Никто не вкладывает деньги в разработку идеального программного обеспечения. Здесь надо делать то, за что платят деньги и делать это быстро. Если программа делает то, что хочет клиент, пусть даже не самым лучшим образом, то все довольны, а мнение программистов никого не касается.

F>Если же надеешься хоть когда-то заняться серьезными вещами, промышленными решениями автоматизации, крупными и сверх крупными информационными системами, програмным обеспечением научно-исследоваательской деятельности. То UML (или что-то подобное, коего море) — это must have, иначе выкинуть тя нахер от туда, там программеры не нужны, нужны только иженеры (умеющие, например, программить .

Теоретики чего-то пишут, это точно. Только на кой ты мне скажи нужна докторская степнь, если технологии меняются очень быстро, а платят не за знание общей теории, а за знание конкретики. В любом случае знать теорию хорошо, но наступает момент, когда надо знать не то, что может технология, а то что она не может, а это как раз практика. За себя скажу, что нет у меня PhD и не будет, но как практик я на голову выше преподавателей в университетах, поскольку занимаюсь реальными задачами (я, например, очень хорошо понимаю что ООП в чистом виде — это зло ). И когда дело дойдёт до поиска работы — меня возьмут быстрее, чем человека без реального опыта (кто хочет поспорить?).

F>А также зависит от того, что ты считаешь (_для себя_) продуктом "разработки програмного обеспечения" (РПО .
F>Если это Код и перед ним ты прекланяешься, думаешь, что хороший код решает проблему, сделал Код и гуляй, то UML тебе тоже не впился, время тратить... и скучно.
F>А вот я напр. не считаю (для себя) код продуктом РПО. Вот для заказчика, да код — это продукт, он его покупает (думает, что покупает решение, а на самом деле покупает код . А для меня код — мусор, благо он уже продан, и у меня его какбы уже и нету. А вот xp'ы набранные в процессе _проектирования_ системы, части построенных моделей — вот это то, что останется у меня, то что мое. И именно это я смогу использовать в других системах. Я вообще скептически отношусь к code reuse, что касается кода проблемной области, потому что он обычно отличается в той степени, в какой отличаются и проблемные области (вопрос о конвеере и почему там так не происходит), и тащить код из одной проблемной области в др можно, как можно писать проги в машинных кодах (а кто говорит, что нельзя?), но полученное решение будет не таким, что можно сказать, лет через 10 — _Я_ это сделал. А вот наработанные части моделей таскать вполне резонно.

Резонно таскать опыт, что в проектировании выражается в форме паттернов. Но не все это могут — не каждый может быть архитектором. Code reuse — это зло, как я уже говорил. В больших системах используется генерация кода, а не его повторное использование. Генерация кода с UML диаграмм — это жалкое подобие того, что порой реально нужно.

F>Мое мнение — незнание UML (или, опять же, другого подобного инструмента), значит привязывать себя к одному языку программирования (ведь именно там остануться все наработки, если (вернее, когла) придется пересесть на другой.

Фигня всё это. Я знаком с UML, но он мне не нужен, чтобы помнить паттерны, а они порой не привязаны к языкам. С другой стороны не так уж и часто происходит скачок на новую технологию. А с выходом .NET про языки вообще можно забыть — надо знать технологию.

F>Thus, ruki proch ot UML, что в переводе с пуэрториканского означает, что знание UML — важно ]

UML — это комерческий продукт фирмы Rational. Поэтому я б не стал его так рьяно защищать

Здравствуйте Mishka.NET, Вы писали:

M.NET>Здравствуйте Frostbitten, Вы писали:

Генерация кода с UML диаграмм — это жалкое подобие того, что порой реально нужно.
Я б сказал, что именно _эти_ генераторы — жалкое подобие тех генераторов, которые нужны. UML тут не причем!

M.NET>UML — это комерческий продукт фирмы Rational. Поэтому я б не стал его так рьяно защищать
UML это не продукт и не рекламная фишка. Это реальная помощь при проектировании больших и средних систем. И его реально используют. Порой с хорошим генератором и не большой задачей разрабока системы превращаеться в рисование!
Это не пустые слова вот пример: в июле в Перми проходил ЧЕ2002 по боксу. Для этого была разработана система информационной поддержки проведения чемпионата. Она разрабатывалась одним разработчиком за месяц (точнее за три недели), включая анализ, рисование диаграмм, дописывание кода и тестирования. Для интереса могу посчитать скока процентов кода от готовой системы было сгенерированно автоматически...

Здравствуйте Toughpheeckouse, Вы писали:

T>Генерация кода с UML диаграмм — это жалкое подобие того, что порой реально нужно.
T>Я б сказал, что именно _эти_ генераторы — жалкое подобие тех генераторов, которые нужны. UML тут не причем!

Не знаю, не знаю. У нас есть внутренние средства для генерирования кода и разработка продукта сводится к описательской работе. И правда — UML тут не причём, он бы только мешал.

M.NET>>UML — это комерческий продукт фирмы Rational. Поэтому я б не стал его так рьяно защищать
T>UML это не продукт и не рекламная фишка. Это реальная помощь при проектировании больших и средних систем. И его реально используют. Порой с хорошим генератором и не большой задачей разрабока системы превращаеться в рисование!
UML — это продукт и его рекламируют. У нас тут гаврики из Rational на прошлой неделе были много чего хорошего сказали про UML и про их взгляд на процесс разработки. С процессом я согласен частями, с использованием UML — нет.

T>Это не пустые слова вот пример: в июле в Перми проходил ЧЕ2002 по боксу. Для этого была разработана система информационной поддержки проведения чемпионата. Она разрабатывалась одним разработчиком за месяц (точнее за три недели), включая анализ, рисование диаграмм, дописывание кода и тестирования. Для интереса могу посчитать скока процентов кода от готовой системы было сгенерированно автоматически...

Могу предположить, что если бы он не страдал хернёй и не рисовал диаграммы, то сделал бы всё за неделю История из реальной жизни: когда я только пришёл в фирму, то на первых порах пытался заставить аналитиков быть конкретнее в их спецификациях. Потом мне менеджер дала по шее и сказала, чтобы я делом занимался, а не бумажки писал. Через пару месяцев, я был удивлён, что всё работает, и никто ничего не анализировал до мелочей. Так что документация — это тоже зло.

А вот тебе другой пример: проектируется система, большая не по количеству классов, а по их разнородности, я честно пытался использовать UML, но забросил всё это когда количество классов перевалило за сотню. UML в этом случае использовать неудобно! Куда как лучше использовать С# Там хоть сразу видно что с чем стыкуется и как, плюс имеешь полуготовый код, который, кстати, ещё и что-то делает, и это что-то можно показать заинтересованным лицам. Да, и в моём случае все Use Cases нарисовать также не удастся — всё ж таки проект большой и он будет эволюционировать.

Здравствуйте Mishka.NET, Вы писали:

M.NET>>За себя скажу, что нет у меня PhD и не будет, но как практик я на голову выше преподавателей в университетах,

Старый спор, ему уж лет 1200 :)... Но, про голову, лучше не говорить, это обычно воспринимается как-то превратно :)))

M.NET>>Только на кой ты мне скажи нужна докторская степнь, если технологии меняются очень быстро, а платят не за знание общей теории, а за знание конкретики.

Никакая технологи еще не создала что-то сложнее того, что было до нее :). А UML, как раз, основывается на понятиях реального мира: интерфейс, взаимодействие, объект, видимость. Есть технологии, кот. не покрывают UML, наоборот может только получиться при моделировании VR :)

T>>Генерация кода с UML диаграмм — это жалкое подобие того, что порой реально нужно.
T>>Я б сказал, что именно _эти_ генераторы — жалкое подобие тех генераторов, которые нужны. UML тут не причем!

%100

M.NET>>UML — это комерческий продукт фирмы Rational. Поэтому я б не стал его так рьяно защищать :)

В этом месте обычно хочется сказать что-то неумное :), но я промолчу. И скажу другое: XML — это продукт микрософт и рекламирует она его как продукт и продает его как продукт :))) Таже хрень. Разберитесь.

Rational предлагает совсем другое, зря вы прогнали агентов, выслушали б, что (imho, за гадость) они предлагают. UML тут не причем.

T>>... в июле в Перми проходил ЧЕ2002 по боксу. Для этого была разработана система ...
M.NET>Могу предположить, что если бы он не страдал хернёй и не рисовал диаграммы, то сделал бы всё за неделю :)

Сделал бы другое. А на следуюющий год сделал бы совсем другое. И еще черех год... Сизифом, короче, звали б пертса :)... Или уволили за то что так много жрет :).

M.NET>>Так что документация — это тоже зло.

... Думал тот менеджер. А я, например, противоположного мнения.

M.NET>А вот тебе другой пример: ... проект большой и он будет эволюционировать ...

А вот это зло. Если большой проект эволюционирует, он не может быть завершен ("а только отложен" (c) Микельанжело /художник/ :). Итеративный проесс предусматривает коррекцию и дополнение проекта, но только не эволюцию (как процесс недискретный и, зачастую, неуправляемый).

И вообще хотелось бы утвердить следующее:

1. UML — это язык. Язык не программирования, а естественный, язык на котором можно объяснить коллеге, а что самое главное, себе что ты думаешь, записать мысль, которую можно будет прочесть через 10-20 лет (с кодом этого не получится). Язык синтезированный из других, разработанный теоретиками проектирования. Этот язык НЕ ИМЕЕТ ничего общего ни с RUP в частности, ни с Rational вообще, за исключение того, что Grady Booch, там идейный вдохновитель (и совладелец?). (точка)

2. Что-то мне не нравиться как остервенело Mishka.NET нападает на UML, этому должны быть какие-то личные причины. :)]

3. Если же тыкать пальтсем на запад, то следует надомнить, что там существует мнение, что программист — это такой электрик, которому платить приходиться во много раз больше. У нас-то совсем подругому. Так это или нет, узнать чрезвычайно сложно (спрашивать у программистов беспользно — кто скажет, что я ... :) Так что кодером до пенсии быть я лично, не собираюсь, потому UML мне пне помешает... для общего развития :), но у кажного свои цели... и для вас UML, действительно может быть бесполезен. Но не будем сориться (хотя мне кажется, что вы имеете смутное представление об UML или я ошибаюсь? :)

Здравствуйте Mishka.NET, Вы писали:

M.NET>Здравствуйте Frostbitten, Вы писали:

M.NET>Вся экономика Запада построена на идее "good enough" ПО. Никто не вкладывает деньги в разработку идеального программного обеспечения. Здесь надо делать то, за что платят деньги и делать это быстро. Если программа делает то, что хочет клиент, пусть даже не самым лучшим образом, то все довольны, а мнение программистов никого не касается.

Сильно task sensetive ...


M.NET>Теоретики чего-то пишут, это точно. Только на кой ты мне скажи нужна докторская степнь, если технологии меняются очень быстро, а платят не за знание общей теории, а за знание конкретики. В любом случае знать теорию хорошо, но наступает момент, когда надо знать не то, что может технология, а то что она не может, а это как раз практика. За себя скажу, что нет у меня PhD и не будет, но как практик я на голову выше преподавателей в университетах, поскольку занимаюсь реальными задачами (я, например, очень хорошо понимаю что ООП в чистом виде — это зло ). И когда дело дойдёт до поиска работы — меня возьмут быстрее, чем человека без реального опыта (кто хочет поспорить?).

Рассуждение как у кодера после колледжа ... не developer'а. Взять то может Вас и возьмут, вот только толку для компании -- не много. Для разовой задачи без развития -- нет проблем. А вот для создания серъезной системы -- вы наваяете кучу кода, и потом свалите туда где больше платят. И что делать менеджеру и другому разработчику с вашей практичностью -- километровыми обработчиками OnClick? А если систему нужно будет писать потом на др. языке программирования?


M.NET>Резонно таскать опыт, что в проектировании выражается в форме паттернов. Но не все это могут — не каждый может быть архитектором. Code reuse — это зло, как я уже говорил. В больших системах используется генерация кода, а не его повторное использование. Генерация кода с UML диаграмм — это жалкое подобие того, что порой реально нужно.


Вы видите системы только с точки зрения кода ... а не сточки зрения системы.


M.NET>Фигня всё это. Я знаком с UML, но он мне не нужен, чтобы помнить паттерны, а они порой не привязаны к
языкам. С другой стороны не так уж и часто происходит скачок на новую технологию. А с выходом .NET про языки
вообще можно забыть — надо знать технологию.


Паттерны чего -- процесса заключения договора, например? А как вы будете применять паттерны, без знания физики процесса? Или Вам быстро, на пальцах пояснят все требования к системе?

Здравствуйте Frostbitten, Вы писали:

F>Никакая технологи еще не создала что-то сложнее того, что было до нее . А UML, как раз, основывается на понятиях реального мира: интерфейс, взаимодействие, объект, видимость.
Всё придумано в 60-х годах. Ничего нового практически нет. Но вот реализация всех идей постоянно меняется, поэтому платят за то, что ты знаешь чем оно всё отличается от теории, то есть особенности реализации.
UML пытается основываться на реальном мире. Или лучше сказать он сжимает мир в свои рамки. Мне с некоторых пор не нравятся идеи ОО, на которых как раз и стоит UML. Аспектно-ориентированное проектирование куда как интереснее и полезнее, но для того, чтобы вписать такой взгляд в UML, язык придётся менять. Ну и где тогда пресловутые 10-20 лет?

F>Rational предлагает совсем другое, зря вы прогнали агентов, выслушали б, что (imho, за гадость) они предлагают. UML тут не причем.
Смешной ты Кто ж таких агентов прогоняет. Мы у них вроде Clear Quest и Clear Case собираемся покупать.

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

M.NET>>>Так что документация — это тоже зло.
F>... Думал тот менеджер. А я, например, противоположного мнения.
А что, правда есть время доки писать? Я б вот вместо этого книжку бы почитал, и то для самообразования полезнее

M.NET>>А вот тебе другой пример: ... проект большой и он будет эволюционировать ...
F>А вот это зло. Если большой проект эволюционирует, он не может быть завершен ("а только отложен" (c) Микельанжело /художник/ . Итеративный проесс предусматривает коррекцию и дополнение проекта, но только не эволюцию (как процесс недискретный и, зачастую, неуправляемый).
Теория, батенька, вещь хорошая. Но разработка ПО — это именно эволюция. Любое ПО является незавершённым. Оно просто в некоторые моменты может удовлетворять требованиям заказчика. А требования как известно эволюционируют. Не надо путать управление проектами в IT с другими проектами, здесь мало общего. Именно поэтому проекты в IT рушатся намного чаще. Специфика, понимаешь...

F>И вообще хотелось бы утвердить следующее:

F>2. Что-то мне не нравиться как остервенело Mishka.NET нападает на UML, этому должны быть какие-то личные причины. ]
У меня есть вопрос, и я его уже в 3 раз повторяю: расскажите как вы используете UML на практике, и что вы с этого имеете? Пока что я придерживаюсь того мнения, что UML — это баловство, без которого можно спокойно обойтись.

F>3. Если же тыкать пальтсем на запад, то следует надомнить, что там существует мнение, что программист — это такой электрик, которому платить приходиться во много раз больше.
Ха. Нет здесь такого мнения. Да и не надо всех программистов под одну гребёнку причёсывть. Вот тут в соседней Англии была вакансия — требуется архитектор, умеющий торговать на уровне CEO — ни хрена себе электрика ищут

F>Так что кодером до пенсии быть я лично, не собираюсь, потому UML мне пне помешает... для общего развития , но у кажного свои цели... и для вас UML, действительно может быть бесполезен. Но не будем сориться (хотя мне кажется, что вы имеете смутное представление об UML или я ошибаюсь?
О UML я имею представление. Поэтому я понимаю, что он мне не может помочь при проектировании. Кстати, кодером я перестал быть уже достаточно давно чего и вам желаю

Здравствуйте byur, Вы писали:

M.NET>>Вся экономика Запада построена на идее "good enough" ПО. Никто не вкладывает деньги в разработку идеального программного обеспечения. Здесь надо делать то, за что платят деньги и делать это быстро. Если программа делает то, что хочет клиент, пусть даже не самым лучшим образом, то все довольны, а мнение программистов никого не касается.
B>Сильно task sensetive ...
Факты на бочку! Если программа делает то, что от неё требуется, то проект закончен, если нет, то нет. Третьего не дано. Никто не будет оптимизировать программу, если за это не платят (это факт!).

M.NET>>Теоретики чего-то пишут, это точно. Только на кой ты мне скажи нужна докторская степнь, если технологии меняются очень быстро, а платят не за знание общей теории, а за знание конкретики. В любом случае знать теорию хорошо, но наступает момент, когда надо знать не то, что может технология, а то что она не может, а это как раз практика. За себя скажу, что нет у меня PhD и не будет, но как практик я на голову выше преподавателей в университетах, поскольку занимаюсь реальными задачами (я, например, очень хорошо понимаю что ООП в чистом виде — это зло ). И когда дело дойдёт до поиска работы — меня возьмут быстрее, чем человека без реального опыта (кто хочет поспорить?).
B>Рассуждение как у кодера после колледжа ... не developer'а. Взять то может Вас и возьмут, вот только толку для компании -- не много. Для разовой задачи без развития -- нет проблем. А вот для создания серъезной системы -- вы наваяете кучу кода, и потом свалите туда где больше платят. И что делать менеджеру и другому разработчику с вашей практичностью -- километровыми обработчиками OnClick? А если систему нужно будет писать потом на др. языке программирования?
Я не developer и не coder, а software arhitect И проектирую я серьёзную систему, конкретнее, программное обеспечение для госпиталей в UK и Ireland. Пока что оно держится на 1 месте по популярности. Так что у меня есть основания что-то утверждать. Если я надумаю сменить работу, то всё будет продолжать работать, поскольку всё в умах людей, а их здесь много.

M.NET>>Резонно таскать опыт, что в проектировании выражается в форме паттернов. Но не все это могут — не каждый может быть архитектором. Code reuse — это зло, как я уже говорил. В больших системах используется генерация кода, а не его повторное использование. Генерация кода с UML диаграмм — это жалкое подобие того, что порой реально нужно.
B>Вы видите системы только с точки зрения кода ... а не с точки зрения системы.
А при чём здесь система? Я говорю, что UML может помочь в описании паттернов, но сами паттерны и без UML живут хорошо. Паттерны знать должен каждый архитектор, а вот для программеров — это желательно, но не обязательно.

B>Паттерны чего -- процесса заключения договора, например? А как вы будете применять паттерны, без знания физики процесса? Или Вам быстро, на пальцах пояснят все требования к системе?
Архитектурные паттерны — то есть как всё организовать, здесь достаточно поверхносто знать требования к системе. Затем прорабатывая детали конкретного этапа проекта, пытаемся использовать паттерны проектирования, чтобы быть готовым к возможным последующим изменениям. То что потом делают программисты, это уже их забота.

Здравствуйте Mishka.NET, Вы писали:

M.NET>Здравствуйте byur, Вы писали:

M.NET>>>Вся экономика Запада построена на идее "good enough" ПО. Никто не вкладывает деньги в разработку идеального программного обеспечения. Здесь надо делать то, за что платят деньги и делать это быстро. Если программа делает то, что хочет клиент, пусть даже не самым лучшим образом, то все довольны, а мнение программистов никого не касается.
B>>Сильно task sensetive ...
M.NET>Факты на бочку! Если программа делает то, что от неё требуется, то проект закончен, если нет, то нет. Третьего не дано. Никто не будет оптимизировать программу, если за это не платят (это факт!).

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

M.NET>Я не developer и не coder, а software arhitect :))

а рассуждаете как кодер :-) (а вообще мне вспоминается дедушка Фрейд ...). Насколько я понимаю, до этого проекта, у Вас не было крупных проектов по созданию КИС, а конфигурирование 1С не считается ...

B>>Вы видите системы только с точки зрения кода ... а не с точки зрения системы.
M.NET>А при чём здесь система? Я говорю, что UML может помочь в описании паттернов, но сами паттерны и без UML живут хорошо. Паттерны знать должен каждый архитектор, а вот для программеров — это желательно, но не обязательно.

Повторюсь, но это взгляд сквозь шоры ...


B>>Паттерны чего -- процесса заключения договора, например? А как вы будете применять паттерны, без знания физики процесса? Или Вам быстро, на пальцах пояснят все требования к системе?
M.NET>Архитектурные паттерны — то есть как всё организовать, здесь достаточно поверхносто знать требования к системе.

И при этом эффективно спроектировать?

Здравствуйте Аноним, Вы писали:

M.NET>>Факты на бочку! Если программа делает то, что от неё требуется, то проект закончен, если нет, то нет. Третьего не дано. Никто не будет оптимизировать программу, если за это не платят (это факт!).
А>еще раз повторю, что это зависит от задачи. Если это разовый продукт, не претендущий на развитие и фирма не является даже нишевым игроком, то всем наплевать ...
Ничего от задачи не зависит. Главное результат.

M.NET>>Я не developer и не coder, а software arhitect
А>а рассуждаете как кодер (а вообще мне вспоминается дедушка Фрейд ...). Насколько я понимаю, до этого проекта, у Вас не было крупных проектов по созданию КИС, а конфигурирование 1С не считается ...
Ну расскжи мне как должен рассуждать архитектор, да и ещё скажи чем ты занимаешься, чтоб хоть понимать обоснованность твоих высказываний.

B>>>Паттерны чего -- процесса заключения договора, например? А как вы будете применять паттерны, без знания физики процесса? Или Вам быстро, на пальцах пояснят все требования к системе?
M.NET>>Архитектурные паттерны — то есть как всё организовать, здесь достаточно поверхносто знать требования к системе.
А>И при этом эффективно спроектировать?
Ну дык а как же Я ж вообще личность не ординарная

Блин, разница во времени не дает реагировать вовремя — у меня ночь, а вы тут при дневном свете беседу без меня ведете.

В общем...

A>>Если не нужна тебе, это не значит, что не нужна никому
M.NET>Это верно. Вот я и хочу узнать кто с этого реальную выгоду получает. По-моему только фирма Rational.

UML используется не только в Rational Rose, но и в куче других продуктов, например в Together. Там кодогенерация делается сразу при рисовании диаграммы классов. Это так, к слову о кодировании и проектировании...

M.NET> Я сижу и проектирую большую систему — у меня нет времени на написание документации и рисовние диаграмм, польза от которых сомнительна.

Ну хорошо, скажи тогда, что получается в результате твоего проектирования? Думаю, тоже подобие диаграмм. Или только словесные описания? Что получается на выходе? Проектирование на уровне в целом системы в какой нотации происходит?
UML был придуман, чтобы облегчить как описание предметной области, так и описание деталей конечной реализации, а не чтобы голову заморочить.

Ты тут в трэде написал, ...
M.NET>Потом мне менеджер дала по шее и сказала, чтобы я делом занимался, а не бумажки писал.

Вот также и мне сказали, и другим то же говорят в моей конторе. Только когда потом из-за отсутствия спецификаций и описаний мне приходилось ломать мозги в чужом коде (криво написаном, при этом), я очень пожалел, что начальство против документирования. К тому же хоть какие-то наброски документации у тебя все равно должны быть — ты же не из головы сразу большие системы пишешь...


M.NET>Пример приведи. Как вы используете UML в проектировании, и как вам это помогает.

ОК, пример из научной работы (на нормальной работе не дают применить )
Проектируем информационныу систему своего института, входящего в состав университета. Охватывать должна большую часть информационных потоков, вовлечено много людей (как будущих пользователей, так и разработчиков). Начальные диаграммы, которые уже используются (работа только началась):
1. Use cases — для оценки происходящего в целом в институте (если это вообще кто-то у нас представляет )
2. Activity diagrams — для оценки действий отдельных частей системы
3. Class diagrams — понятно...
4. Сразу же deployment diagrams — разброс по оставным частям, т.к. система постепенно реализовывается в коде по мере детального проектирования отдельных частей.

Это только начало. Если учесть, что разработку и проектирование отдельных частей ведет не один человек, то без предварительых проработок никак нельзя.
Можно конечно не в UML проектировать, но он для этой цели хорошо подходит.
Это достаточный пример для использования UML?


Может кто еще расскажет про свой опыт UML?

Здравствуйте Максим Алексейкин, Вы писали:

МА>Здравствуйте Flea, Вы писали:

F>>Что господа программисты могут сказать о целесообразности изучения сабжа?

МА>Пробовал приобщиться, но бросил за ненадобностью. Гораздо эффективней применять теорию конечных автоматов.

Не могли бы Вы привести небольшой пример использования теории конечных автоматов применительно к проектированию программных систем

Здравствуйте Aquary, Вы писали:

A>>>Если не нужна тебе, это не значит, что не нужна никому
M.NET>>Это верно. Вот я и хочу узнать кто с этого реальную выгоду получает. По-моему только фирма Rational.
A>UML используется не только в Rational Rose, но и в куче других продуктов, например в Together. Там кодогенерация делается сразу при рисовании диаграммы классов. Это так, к слову о кодировании и проектировании...
На самом деле я хотел сказать, что поскольку все создатели UML работают в Rational, то UML можно считать продуктом этой фирмы со всеми вытекающими отсюда проблемами.

M.NET>> Я сижу и проектирую большую систему — у меня нет времени на написание документации и рисовние диаграмм, польза от которых сомнительна.
A>Ну хорошо, скажи тогда, что получается в результате твоего проектирования? Думаю, тоже подобие диаграмм. Или только словесные описания? Что получается на выходе? Проектирование на уровне в целом системы в какой нотации происходит?
А на выходе получается прототип системы, полурабочий, но его хоть можно показать. А за рисование диаграмм надают по шее, и правильно сделают, поскольку толку от диаграмм не много.

A>Вот также и мне сказали, и другим то же говорят в моей конторе. Только когда потом из-за отсутствия спецификаций и описаний мне приходилось ломать мозги в чужом коде (криво написаном, при этом), я очень пожалел, что начальство против документирования. К тому же хоть какие-то наброски документации у тебя все равно должны быть — ты же не из головы сразу большие системы пишешь...
Пишу не с головы, а с опыта Мне легче — я точно знаю, что нужно. А менеджеров не стоит недооценивать, у них свои резоны на такое "невменяемое" поведение.

A>ОК, пример из научной работы (на нормальной работе не дают применить )
Вот именно! На практике UML нет места. Только в институтах

A>Это достаточный пример для использования UML?
Нет. Покажи мне где выгода от использования UML в данном проекте. Почему нельзя было собрать команду и заставить набросать рабочий прототип будущей системы, а потом менять его (да хоть полностью) по мере необходимости?

A>Может кто еще расскажет про свой опыт UML?
Никто Потому что никто реальной пользы от этого не имеет.

Здравствуйте Mishka.NET, Вы писали:

M.NET>Мне с некоторых пор не нравятся идеи ОО, на которых как раз и стоит UML. Аспектно-ориентированное проектирование куда как интереснее и полезнее.

Не исключаю. Когда-то перлись от процессного (aka структурного) подхода. К совоему стыду не знаю что есть "Аспектно-ориентированное проектирование": пару-тройку keyword'ов для поиска бы или ссылку какую.

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

M.NET>... UML, язык придётся менять. Ну и где тогда пресловутые 10-20 лет?

Ну стоит отметить, что UML достаточно красноречив, чтоб понять нарисованные концептуальную модель или даже диаграмму классов смог любой мало-мальски представляющий концепцию OOПодхода... Даже менеджер, даже (если жестоко заставить :) заказчик.

F>>Rational предлагает совсем другое, зря вы прогнали агентов, выслушали б, что (imho, за гадость) они предлагают.
M.NET>Смешной ты :) Кто ж таких агентов прогоняет.

А надо было! :)]

F>>Сделал бы другое. А на следуюющий год сделал бы совсем другое. И еще черех год... Сизифом, короче, звали б пертса :)... Или уволили за то что так много жрет :).
M.NET>Начальство это не волнует. Оно на изменениях деньги зарабатывает. Да и програаммеру от этого хорошо — вечный прогресс :) А чайники, которые всё это покупают, порой не задумываются на счёт того, что некоторые изменения стоили бы дешевле, если б у программы был хороший дизайн.

У-ууу. Да, я подозревал о существовании у вас этой точки зрения (глядя на подпись :). То, что вы написали здесь, очень хорошо можно экстраполировать на:

Война — это хорошо, потому что хорошо солдатам (им за это платят... в нормальной армии) и вдвойне хорошо генералам (начальникам, в вашей терминологии) — им еще больше платят + побрякушки дают и сапоги именные.
Голод — это хорошо (фермеры).
Болезни — хорошо (фармацевты и тп).

Попробуйте доказать, что не это хотели сказать (а если это... то кто из нас Frostbitten? :).

Нет, я не согласен. Прогдесс — это поднятие на уровень вверх, когда что-то можно УЖЕ не делать, а когда из года в год одно и тоже, какой програсс? Эт сафари на слонов!

M.NET>У меня есть вопрос, и я его уже в 3 раз повторяю: расскажите как вы используете UML на практике, и что вы с этого имеете? Пока что я придерживаюсь того мнения, что UML — это баловство, без которого можно спокойно обойтись.

Мы рисуем диаграмки классов, чтоб посмотреть кто с кем завязан, рисуем диаграммы состояний, понятно за чем, еще много рисуем чтоб понять подсистемы и как они связаны, и чтоб понять что разработчик _хотел_ сделать (ведь как разработчикам нам мало важно что он _сделал_ и _как_, ведь вариантов много). Никакой генерации кода. Накакого Rational.

Обойтись можно безо всего! Пушкин, чай, не в LaTeX'е воял :).

Хм... к стати, memnto more (или как это там пишется :). А если вас... эм... ... похитят инопланеняне :), очевидно, вместе с вашим богатым обытом... как будет чувствовать себя ваша компания, лишившись архитектора, кот. не оставил, нахер, никакой документации, только код. :) А вопрос этот стоит здесь очень остро — текучка кадров.

P.S. Приятно было пообщаться, позиция ваша мне понятна, обоснованная позиция, но непреемлемая, например, для меня :).

Здравствуйте Frostbitten, Вы писали:

F>Здравствуйте Mishka.NET, Вы писали:

M.NET>>Мне с некоторых пор не нравятся идеи ОО, на которых как раз и стоит UML. Аспектно-ориентированное проектирование куда как интереснее и полезнее.

F>Не исключаю. Когда-то перлись от процессного (aka структурного) подхода. К совоему стыду не знаю что есть "Аспектно-ориентированное проектирование": пару-тройку keyword'ов для поиска бы или ссылку какую.


Пользуйся cool site.

Но я бы не сказал, что ОО и АОР противоречат друг другу. По-моему это разные уровни абстракции.

Здравствуйте Frostbitten, Вы писали:

F>Не исключаю. Когда-то перлись от процессного (aka структурного) подхода. К совоему стыду не знаю что есть "Аспектно-ориентированное проектирование": пару-тройку keyword'ов для поиска бы или ссылку какую.

http://aosd.net. Уже успели даже книжку выпустить — "Программирование на AspectJ".

F>У-ууу. Да, я подозревал о существовании у вас этой точки зрения (глядя на подпись . То, что вы написали здесь, очень хорошо можно экстраполировать на:
F>Война — это хорошо, потому что хорошо солдатам (им за это платят... в нормальной армии) и вдвойне хорошо генералам (начальникам, в вашей терминологии) — им еще больше платят + побрякушки дают и сапоги именные.
F>Голод — это хорошо (фермеры).
F>Болезни — хорошо (фармацевты и тп).
F>Попробуйте доказать, что не это хотели сказать (а если это... то кто из нас Frostbitten? .
Вообще-то я так и думаю Мне чужды человеческие ценности А, кстати, Frostbitten — это "обмороженный" или "отмороженный"?
Да, и прекращай общаться на Вы, 1) может оказаться, что я младше тебя. 2) так принято на RSDN. 3) да и вообще смущает официальность

M.NET>>У меня есть вопрос, и я его уже в 3 раз повторяю: расскажите как вы используете UML на практике, и что вы с этого имеете? Пока что я придерживаюсь того мнения, что UML — это баловство, без которого можно спокойно обойтись.
F>Мы рисуем диаграмки классов, чтоб посмотреть кто с кем завязан, рисуем диаграммы состояний, понятно за чем, еще много рисуем чтоб понять подсистемы и как они связаны, и чтоб понять что разработчик _хотел_ сделать (ведь как разработчикам нам мало важно что он _сделал_ и _как_, ведь вариантов много). Никакой генерации кода. Накакого Rational.
Да, наверно это помогает. Я умудряюсь все связи и взаимоотношения в голове держать.
F>Обойтись можно безо всего! Пушкин, чай, не в LaTeX'е воял .
У-у-у, дай я тебе пару баллов за Пушкина накину

F>Хм... к стати, memnto more (или как это там пишется . А если вас... эм... ... похитят инопланеняне , очевидно, вместе с вашим богатым обытом... как будет чувствовать себя ваша компания, лишившись архитектора, кот. не оставил, нахер, никакой документации, только код. А вопрос этот стоит здесь очень остро — текучка кадров.
У нас нет текучки кадров. Я ещё в своём уме и из такой компании не уйду — видано ли в России, чтобы если сборная страны по футболу играет, то фирма снимает местный паб, чтоб всем скопом матч смотреть, покупает всем пиво и никто не работает в этот день Ну и плюс никто не напрягает, тишина и покой. Деньги платят во-время и хорошие. Снега тут нет, всегда плюс, но не жарко. Скажи мне, ты б ушёл с такой работы?

F>P.S. Приятно было пообщаться, позиция ваша мне понятна, обоснованная позиция, но непреемлемая, например, для меня .
А то как же, затем и общаемся

Здравствуйте Mink, Вы писали:

M>Но я бы не сказал, что ОО и АОР противоречат друг другу. По-моему это разные уровни абстракции.
Скорее AO — это развитие идей ОО. К тому же AO может использовать ОО, привнося туда только концепцию аспектов.

Здравствуйте Flea, Вы писали:

F>Здравствуйте Максим Алексейкин, Вы писали:

МА>>Здравствуйте Flea, Вы писали:

F>>>Что господа программисты могут сказать о целесообразности изучения сабжа?

МА>>Пробовал приобщиться, но бросил за ненадобностью. Гораздо эффективней применять теорию конечных автоматов.

F>Не могли бы Вы привести небольшой пример использования теории конечных автоматов применительно к проектированию программных систем

State Machine Diagramm из UML :-)))

Здравствуйте Mishka.NET, Вы писали:


M.NET>>>Я не developer и не coder, а software arhitect
А>>а рассуждаете как кодер (а вообще мне вспоминается дедушка Фрейд ...). Насколько я понимаю, до этого проекта, у Вас не было крупных проектов по созданию КИС, а конфигурирование 1С не считается ...
M.NET>Ну расскжи мне как должен рассуждать архитектор, да и ещё скажи чем ты занимаешься, чтоб хоть понимать обоснованность твоих высказываний.

Наверно, Вы таки стоит говорить ... Я занимаюсь КИС для РАО ЕС и Региональных энергокомпаний

Здравствуйте byur, Вы писали:

B>Наверно, Вы таки стоит говорить ... Я занимаюсь КИС для РАО ЕС и Региональных энергокомпаний

Помню настраивал я 1С для Карелэнерго