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

Как мне недавно объяснили очень авторитетные люди, в России используется тольно Use Cases и Class - диаграммы потому, что остальное по большому счёту - неоправданная трата денег. При использовании всего арсенала UML с целью автогенерации основного каркаса кода с тем, что бы вписывать потом функционал, проект выростает в цене практически в 2 или больше раз - ни один заказчик на это не идёт.

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

Возможно, если бы все сели и стали проектировать перед программированием, то достаточно быстро возникла бы культура и написания программ по UML`у, которая увеличила бы темпы и качество написания кода, но на первых порах нужно преодолеть этот ценовой барьер, на что мало кто согласился бы добровольно пойти - по крайней мере у нас... А по сему, у меня создаётся печальное мнение, что нам остаётся только надеяться, что моделирование станет более актуальным в будущем, в которое мы опять попадём вторыми, только после Запада - на его опыте удешевления использования моделирующих средств, адаптированном под нас

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

Использую только class диаграммы.

Я просто в ШОКЕ.

Цитата

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

Значит эти люди ничего не слышали про Together ControlCenter или Together Architect. А если им назвать Rational Rose или технологию создания MDA-приложений с использованием ECO, то они совсем будут в дауне.

Цитата

проект выростает в цене практически в 2 или больше раз - ни один заказчик на это не идёт.

Ага. А еще его делают раз в 10 дольше. Тоже слышал. Ну как тебе тут сказать...

Цитата

Возможно, если бы все сели и стали проектировать перед программированием, то достаточно быстро возникла бы культура и написания программ по UML`у, которая увеличила бы темпы и качество написания кода

Всеми руками ЗА

Цитата

моделирование станет более актуальным в будущем, в которое мы опять попадём вторыми, только после Запада

Ничего подобного.

В Питере давно действует такая организация как TogetherSoft. Java-программисты должны знать. Она и делает как раз софт для проектирования и разработки корпоративных приложений. Я называл уже выше. Ета фирма оказалась такой хорошей, что ее купила Borland, а теперь из-за нее собирается купить и мелкософт вместе с Borland'ом (читать письмо ниже!). И все из-за того, что стормозила с Rational, отдав ее IBM.
Совет: почитайте книгу профессионалов из TS: "Java 2, Enterprise Edition. Технологии проектирования и разработки. Иванова Е. Б., Вершинин М. М. - СПб.: БХВ-Петербург, 2003 - 1088 с." Java-программисты просто обязаны ее прочитать. Богом прошу!
Уф. Ну а теперь письмо, чтобы скучно не было. Оно уже на форумах фигурировало.

The acquisition spotlight fell on Microsoft Corp yesterday, as speculation swept Wall St that the company was moving against Borland Software Corp as well as Rational Software Corp to revive its application design and modeling offerings, writes Gavin Clarke.

Redmond, Washington-based Microsoft was reported to be preparing the acquisition of its number-one competitor in the Windows developer space, Borland. Boland itself recently bought design and modeling specialist TogetherSoft SA.

Such a deal would provide Microsoft access to TogetherSoft's resources, after IBM announced its proposed $2.1bn acquisition of independent application design and modeling specialist Lexington, Massachusets-based Rational Software earlier this month.

Microsoft, on Wednesday night, was also rumored to be preparing a counter-bid to IBM's multi-billion offer for Rational.

One ISV source, who wished to remain anonymous, said: "Don't discount the rumor [Microsoft] are mounting a competing bid. It will be an expensive counter bid."

A Microsoft source insisted the company was "in no way, shape or form" going to outbid IBM for Rational. Microsoft, meanwhile, refused to comment on a possible Borland acquisition.

Microsoft has insisted that it would not suffer from the loss of Rational to IBM, as the company has other partners in this area. Rational has been a partner of Microsoft on .NET, integrating tools such as Rose and XDE with Visual Studio.NET.

However, Borland chief executive Dale Fuller summed up the loss to the industry of Rational's independence. Borland was a Rational partner.

"As a customer, it's taken away my ability to use the industry standard development platform [Rational's Rose product]. We will continue to support [Rose] but the tight integration we could have had, we are not going to get," Fuller told a financial analysts' conference.

Microsoft's own application design and modeling portfolio is believed to have been weakened by IBM's acquisition, as this will reduce opportunities for tigher integration between Rational's and Microsoft's products.

Of equal importance to Microsoft is the loss of Rational's services arm. This $90m business was capable of advising organizations over how to design and implement scalable, enterprise-class .NET systems. Those consultants, while serving .NET inside IBM, will now be constrained when selling against Java by IBM's adherence to Java through WebSphere.

The rumors of a strike by Microsoft against Borland and Rational ignited as it emerged Microsoft may have missed out - either by design or by mistake - on the opportunity to buy Rational as recently as August.

In a Securities and Exchange Commission (SEC) filing, published yesterday, Rational said that during the midst of its discussions with IBM, company founder and chief executive Michael Devlin was contacted by telephone by representatives of a company interested in renewing earlier discussions with Rational over a possible "business combination transaction."

Rational did not name that company, referring to it simply as "Company A" but circumstantially that puts Microsoft solidly in the frame. Microsoft has told ComputerWire its executives discussed a possible acquisition of Rational to fill-out its own offerings.

The SEC filing said: "During the period thereafter and leading up to the December 6, 2002 announcement of the proposed merger with IBM, numerous conversations occurred between representatives of Company A and us or representatives of our financial advisor, Goldman Sachs. However, these conversations never resulted in a detailed discussion of proposed terms or Company A submitting a specific indication of interest.

A Microsoft spokesperson said he could not comment on the details of the SEC filing and Rational would not comment on either the filing or a possible Microsoft bid.

Весь проект в CASE UML

Есть такой проектировщик Мартин Фаулер. Так он в своей книге (UML основы) пишет, что если момент в системе критичен, то он строит для него и диаграмму классов, и диаграмму взаимодействия и вариант использования, короче как можно более подробно, но это за собой тянет поддержку по версиям, значит доп. время. На мой взгляд, весь проект проектировать до мельчайших подробностей CASE с UML не нужно (кстати это и противоречит RUP), нужно отразить в этих диаграммах самые критичные моменты, и их строго формализовать, все остальное - это дело творчества программистов а не проектировщиков. Проектировщику самое главное сказать где, когда, и что... а программист должен ответить как...

Генерация кода

Это дело хорошее, но требует много усилий. Нужно все ДЕТАЛЬНО рисовать, а это попросту иногда не нужно (по причинам описаным выше).

Культура программирования

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

Расширение модели

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

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

Это сообщение отредактировал(а) np9mi7 - 13.4.2005, 07:56

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

Я вот его знаю немного - а что толку? На практике ни разу диаграммы не получал и не составлял (исключая учебные примеры). Вот в Билдере есть такая фича - автопостроение диаграммы классов. Пробовал изучать проект по ним, но по коду оказалось легче...

Хорошо написал, np9mi7. Позволю прокомментить.

Цитата(np9mi7 @ 13.4.2005, 08:49)

весь проект проектировать до мельчайших подробностей CASE с UML не нужно

Корпоративный программный продукт - обязательно. В смысле выигрыш огромный по времени, а значит и стоимости.

Цитата(np9mi7 @ 13.4.2005, 08:49)

Это дело хорошее, но требует много усилий. Нужно все ДЕТАЛЬНО рисовать, а это попросту иногда не нужно (по причинам описаным выше).

Объясняю: то, что "рисуешь" - не пишешь.

Цитата(np9mi7 @ 13.4.2005, 08:49)

НУ а по поводу рисовать и лень - это да.

Все просто и быстро. Откройте любой UML редактор. Наглядность, доступность, понятность, переносимость, расширяемость, скорость.

Цитата(np9mi7 @ 13.4.2005, 08:49)

В этом и кайф проектирования - построить модель которая легко расширяется...

Человек - ДУМАЕТ больше в начале. Результат от этого только лучше. К сожалению, метрики никакие не могу дать...

Цитата(np9mi7 @ 13.4.2005, 08:49)

многие члены комманды могут вообще нихрена не знать UML или испытывать к нему отвращение

Цитата(En_t_end @ 13.4.2005, 20:27)

UML не знаю

В графических UML-редакторах почти ничего знать не надо.

Цитата(Cr @ 13.4.2005, 23:01)

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

Документировать все бессмысленно. Например, нафига рисовать диаграмму состояний для объекта, состояние которого тебя абсолютно не интересует?

Цитата

Корпоративный программный продукт - обязательно. В смысле выигрыш огромный по времени, а значит и стоимости.

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

Цитата(np9mi7 @ 14.4.2005, 12:30)

ты на этапе проектирования знаешь как все до мельчайших подробностей работать будет? Я думаю нет... Или я не прав?

Ну, в общем-то, в идеале, должно быть именно так, на то оно и проектирование. Концептуальное => логическое => физическое или-как-там-оно-называется. Последний этап проектирования должен дать нам модель, которую остается только закодировать. Но вот достижимо ли это?

Цитата(Lamer @ 14.4.2005, 12:29)

Например, нафига рисовать диаграмму состояний для объекта, состояние которого тебя абсолютно не интересует?

Пока не интересует.

Цитата(np9mi7 @ 14.4.2005, 13:30)

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

Всего знать нельзя. Но, чем лучше продумаешь проект, тем лучше для тебя.

Цитата(Lamer @ 14.4.2005, 14:30)

Последний этап проектирования должен дать нам модель, которую остается только закодировать. Но вот достижимо ли это?

Код генерится автоматически, вносишь саму логику, что на диаграммах не показать.

Ко всем постам - дело творческое, на многие вопросы может ответить только опыт, так не объяснить. Сам большого не имею. Очень часто трудности просто концептуальные. Кому действительно интересно - читайте книженцию - правда, очень толковая. Там все аспекты этого.

Недавно попробова подизайнить UMl в Visio 2003. Понравилось
Играет роль ещё то, что человеку более свойственны обьекты (пусть их изображение) чем буквы и цифры.

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

Цитата(chipset @ 18.4.2005, 07:29)

что человеку более свойственны обьекты (пусть их изображение) чем буквы и цифры.

Воот. Становится более наглядно и интуитивно понятно тут же.

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