Меня начинает угнетать тот факт, что даже в профессиональных и высоких 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-ти кассов будешь долго понимать их сложную иерархию наследования, по диаграмме - практически сразу.

Прочитал пол-Фаулера
Теперь ещё буду активити, пакедж и юзэкэйс диаграммы юзать

UML - НУЖЕН, не даром ведь Буч и вся остальная компания так долго с им занимались... , нужен нужен, точно говорю, это просто....

А то что типа нужно все знать сразу это и есть проектирование - это утопия, так не бывает....

Я считаю что UML нужен как средство кооперации Аналитика, Архтектора и Разработчика. Во многих книгах по УМЛ идёт сравнение строительства дома и разработки ПО, что в обоих случаях должен получиться качественный продукт, это стоит затрат, т.к. отдача будет адекватна. Заложив хороший "фундамент" и определившись какой будет дом, с какими стенами, потолком, полом, открыванием/закрыванием окон и дверей, комуникаций и пр. будет гораздо проще и быстрее его построить, а в нашем случае разработать хороший и качественный софт.
Другое дело что это у нас пока не получило распространения, действительно, на тебя (если ты предлагаешь использовать УМЛ пускай даже в небольшом проекте, просто как начало нового способа разработки) смотрят как на романтика или как на Чапая сидящего на коне махая шашкой. Внедрять УМЛ в разработку (не имея понимающей в УМЛ команды ) получается накладно, потому что в результате можно проковыряться с изучением УМЛ и ничего дельного толком не сделать. Вывод: УМЛ уместно применять (на мой взгляд):
1. когда команда разработчиков понимает УМЛ.
2. когда реально используется какой-то процесс анализа, проектирования, разработки, тестирования, внедрения, сопровождения.
3. применять его лично для себя, для понимания тех или иных моментов проектирования системы, алгоритмизации и т.д.

Для себя сделал вывод такой: сколько я в одиночку не пытался использовать УМЛ, но далее диаграмм использования, активити и классов дело не шло, мне было просто дальше влом заниматься рисованием.
Но потом я понял почему, потому что очень сложно перестроиться из текстового восприятия (обычный исходный код) к графическому, потому что в сознание остаётся клин о том что это всё равно нужно будет переписывать в текст (автогенеринг кода или руками не важно). У меня был точно такой же ступор когда я переходил с процедурного программирования на объектный. И пришёл к выводу, что нужно ещё и ещё раз пробовать использование УМЛ в своих проектах, всё дело в практике. В любом случае через какой-то момент времени получится проект и тогда я думаю реальный комфорт осознается.
Главное знать куда идти, а путь всё равно проложится.

Верное мнение.

Наглядное графическое изображение всегда хорошо. Стандартизированное еще лучше. Но рассматривать UML как панацею наверно не правильно. Я вижу следующие проблемы с UML:
- неполная поддержка рисовалками (например RationalRose),
- динамику, т.е. сам алгоритм к сожалению не более удобно рисовать, чем в любом графическом редакторе.
- при генерации диаграммы из кода коллекции встают стеной: мне совсем не нужно на диаграмме видеть, что класс ссылается на ArrayList, мне нужно видеть, что класс ссылается на список объектов класса С2.

Мысль конечно слишком спорная, чтобы оставлять ее без примеров. Вот и примеры:
1) Как описать альтернативные связи между классами ?
2) Как описать алгоритм, выполнение которого проходит через 5 разных классов ?
3) Как описать, что метод М использует классы С1 и С2 (именно метод) ? (в стандартном UML это есть, а в Розе нет).
4) Как показать, что делают методы класса в его разных состояниях ?
5) Как показать, что объект класса С1 вызывает метод М у объекта класса С2 и передает ему объект класса С3 (по логике это д.б. возможно на sequrence или colaboration диаграммах) ?

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

Нас в универе тоже очень упорно знакомили с этими многочисленными диаграммами. Брали фиктивные проект и прямо по схеме концепт->логика->физический уровень строили. Поэтапно составляешь эти диаграммы.

1. Бизнес план + Business Process Model
2. Спецификация требований для проекта (я по-русски не знаю, как будет)
3. Use case model
4. Activity diagram
5. Class diagram
6. Statechart
7. ERA diagram

План можно ещё расширить на другими схемами.

И это всё рисовали. В универе упор на это и делается: главное - это аналитика, подготовка проекта, планирование. Программирование - в последнюю очередь, и вообще, программировать должны программисты, а мы, типа, им всё на блюдечке подать

Потом в PowerDesigner -в конце концов и код писать не надо, он сам сгенерирует (Java, .. ). Не знаю, на фиктивных вещах это всё так скучно, что интерес пропадает. На практике ведь всё по-другому. А так подумать - спасибо, что хоть какие-то практические навыки дали, а то университетское образование известно своей академичностью - выпускники учили кучу вещей, а как это всё выглядит на практике, не знают.

Оно, может, и удобно, когда проект состоит из нескольких модулей, сотни классов, группа разработчиков, да ещё и на разных языках всё это пишется. Для мелких проектов это лишне и переплачивать за это никто не будет. Хотя преподы пытаются донести мысль о том, что и на маленьких проектах нужно соблюдать культуру создания ИС: всё делать по плану, всё рассчитывать. Минус в том, что большая часть студентов потом всё равно не будет работать с такими большими проектами, где без UML (даже не обязательно их уметь составлять - на это аналитики есть, а просто понимать, как член команды разработчиков) не обойтись.

Цитата(lovermann @ 20.7.2005, 14:19)

Оно, может, и удобно, когда проект состоит из нескольких модулей, сотни классов, группа разработчиков, да ещё и на разных языках всё это пишется. Для мелких проектов это лишне и переплачивать за это никто не будет. Хотя преподы пытаются донести мысль о том, что и на маленьких проектах нужно соблюдать культуру создания ИС: всё делать по плану, всё рассчитывать. Минус в том, что большая часть студентов потом всё равно не будет работать с такими большими проектами, где без UML (даже не обязательно их уметь составлять - на это аналитики есть, а просто понимать, как член команды разработчиков) не обойтись.

Я тоже так думал, пока работать не начал

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

Цитата

...что и на маленьких проектах нужно соблюдать культуру создания ИС: всё делать по плану, всё рассчитывать...

ИС уже под собой подразумевает что проект не маленький

Class Diagrams для проектирование и реинжиниринга. И различного рода вспомогательные рисунки и чертежи, если нужно.

javastic, ИС - я сократил "информационная система". Маленькая фирмочка: интранет + сайт -- это ведь тоже информационная система уже в своём роде, только для неё команды разработчиков не надо.

Lamer George, спасибо за делёжку опытом

Цитата(lovermann @ 20.7.2005, 16:15)

Lamer George, спасибо за делёжку опытом smile

Он у меня невелик

Итак. В последнее время (с апреля) я довольно активно занимался проектированием в UML, правда проект не сложный по сути (3D игра). Могу выделить несколько моментов из своего опыта:
1) UML рулит.
2) См. 1)
Если серьёзно, то:
1) Лучше не создавать с самого начала очень детализированных диаграмм, имхо такой подход:
"Сначала все-всё спроектируем, до метода у самого распоследнего класса а потом сядем и будем писать реализацию."
не прокатывает.
У нас в проекте используеться в основном проектирование отдельных модулей с точностью до отдельного класса, но не дальше.
2) Мой 4-месячный опыт показал что лучше как можно быстрее сесть писать код, ибо при написании кода приходят мысли о полной перекройке UML диаграммы, что и приходиться делать.
Таким образом, по Фаулеру мы используем UML для проектирования набросков, чертежей, чисто для того чтобы самому понять как будет работать программа а также обьяснить команде.
3) При этом я использовал Visio 2003, class и package диаграммы с отдельными элементами из sequence и component диаграмм, какой символ больше подходил под описание такой и использовали, опять-же, чисто для скетчей.

Никогда не пользовался UML. Я люблю писать своими руками. Может для следующей программы и и буду использовать UML.
Посему вопросы:
Как в UML поддерживается постоянное изменение требований со стороны заказчика? Use cases по-моему говорят о уменьшении времени итераций разрабатываемого проекта. Но так собственно и происходит в реальной жизни.
Если я изменяю иерархию классов в программе, я должен это делать только с помощью UML?
Что делать с имеющимся кодом, написанным руками?
Кроме каркаса классов что-нибудь генерится?

Я думаю что UML не получил большого распространения, потому что он по большому счету ничего нового не привнес. Ту же диаграмму классов я нарисую на бумаге, напишу каркас классов. Всю функциональность все равно придется писать в функциях. Тоже самое с use case. Методология от Rational описывает то, что уже имеется. Проектирование, программирование, тестирование и развертывание... Просто введены новые понятия и все.

Это сообщение отредактировал(а) Denn - 13.8.2005, 18:33

Вот неплохая статья:
http://ooad.asf.ru/develop/articles/UMLinRussia.asp

Цитата

UML в России. Наступит ли следующий день? Автор: А. А. Погудин С приходом унифицированного языка моделирования мировоззрение большинства программистов стало коренным образом меняться. Теперь при помощи этого языка пытаются документировать не только программное обеспечение но и экономические, социальные процессы и т.д. Безусловно, это одно из величайших изобретений в области программирования (или проектирования, если вам будет так удобней), сопоставимое с такими понятиями, как, например, алгоритм или ООП. В адрес этого языка уже было сказано много хороших отзывов, думаю, вам они так или иначе известны, поэтому не буду их перечислять. В этой статье я хочу взглянуть на унифицированный язык с несколько иной точки зрения. Итак, прошло уже более 5 лет с момента выпуска UML версии 1.1 (1997), с того момента вносилось много изменений и дополнений. Попробуем подвести кое-какие итоги. На мой взгляд, развитие языка опережает ход мыслей: до сих пор нет четких нотаций языка, по крайней мере в русскоязычных изданиях. Книг по этой тематике издается огромное множество, как российскими, так и зарубежными специалистами. Причем нотация не просто расширяется, как было обещано разработчиками UML, она изменяется, причем подчас коренным образом! В результате человек, прочитав одну книгу об UML, может попросту не понять содержимое другой книги. Немаловажную роль играет перевод. Вот пример, который мне встретился в книге Джеймса Рамбо (James Rambough) "UML. Специальный справочник" в переводе Максимовых: известное слово "Actor" они переводят как "Актант". Согласитесь, немного странно, когда привыкаешь к слову "актер", или "исполнитель" и тебе "навязывают" третий вариант перевода... Такие случаи не единичны и многие российские программисты находят выход в том, чтобы вообще не использовать русский перевод терминов а пользуются английскими словами в оригинале. Как результат (и это тоже реальный пример из жизни) иногда "английские" проектировщики не могут понять "русских", что само по себе идет в разрез с ключевым словом "унифицированный". Я не могу говорить здесь о первоисточнике нотации UML, но это можно утверждать о всевозможных русскоязычных книгах. Но тем не менее, коренные различия в версиях позволяют вести проектировку лишь на абстракциях, потому как со стандартным набором знаний об UML (2-3 изученных книги) вы никогда не сможете написать готовое приложение. Кстати о приложениях. Любого заказчика, а следовательно и проектировщика, чтобы там не говорили, интересует прежде всего конечный работающий продукт. На уровне примитивных диаграмм анализ и проектирование ведется достаточно быстро и без особых затрат. Это проверенные факты, но на основе этих данных ни одно CASE-средство не сгенерирует программный код, необходимо, мягко говоря, более детальное описание. Опять же, та же Rational Rose может наотрез отказываться принимать ту нотацию, к которой вы привыкли из-за нечеткого определения языка. А вы пробовали писать конечный продукт, допустим, в Rational Rose? Я вот лично не представляю, как это может выглядеть. Чтобы написать программу из разряда "Hello, World" или "процедуру выдачи чего-то", достаточно базовых знаний любого языка программирования. А вот готовый проект, который можно передать, например в Visual C++... Например, программу расчета зарплаты. Здесь вам будет явно недостаточно принципов "сотрудник работает на дядю n рабочих дней и после авторизации получает x долларов". Кто писал подобные вещи - знает. Знает также и российское законодательство, которое каждый год и не по одному разу меняется во всех сферах, причем одним росчерком пера, а вот проект на UML изменить будет сложнее. Потому как у нас не только вносят поправки, но и изменяют и отменяют. Иными словами, попросту отменяют существующую модель. Но допустим, несмотря на все это, вам все же удается написать более-менее сложный проект, который оформляется в виде программного кода. Если быть точным, вы получите код на языке, популярном на западе. Там все более-менее понятно, у них мало кто знает о существовании той же Borland Delphi. В России картина совершенно иная: добрая половина программистов используют в своей работе Pascal-языки, кроме того, не все пишут на Visual C++ - Borland C++ Builder все же имеет отличия от Visual С. И опять же, если мы все будем писать программы на одном языке или разработчики CASE-средств выпустят инструментарий, понимающий все языки программирования, мы опять натыкаемся на подводные камни. Это правка кода - думаю, что код подправлять придется в любом случае. А когда изменится модель и снова выгружать код, это что же, еще раз править? В подтверждение всему хочу сказать, что если где-то и существуют нормально функционирующие полные модели (Well Formed Model) сложных систем, то их, увы единицы. Пока же все работы на UML ограничиваются только документацией проектов для обеспечения понимания процесса среди разработчиков. В заключении должен отметить, что все вышесказанное является чисто субъективной точкой зрения автора и никак не претендует на объективное мнение большинства, поэтому очень хотелось бы услышать ваши отзывы и решения по данным проблемам.

Это сообщение отредактировал(а) Се ля ви - 23.8.2005, 19:11

Цитата(lovermann @ 20.7.2005, 15:15)

javastic, ИС - я сократил "информационная система". Маленькая фирмочка: интранет + сайт -- это ведь тоже информационная система уже в своём роде, только для неё команды разработчиков не надо. Lamer George, спасибо за делёжку опытом

Спору нет.

Цитата

Меня начинает угнетать тот факт, что даже в профессиональных и высоких 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.

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

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

А что же им преподают, как не это?

Важно даже не то, что преподают, имхо гораздо важнее то, КАК преподают.

Но это уже флуд. Давайте вернемся к теме обсуждения.

Dian, KeenGravy, Pegas, lovermann, Lamer George, ну вот вы к примеру книжки по языку читали? Буча, Лармана, Фаулера? Если читали - вам и так все понятно. Если не читали - то сначала стОит прочитать хотя бы штучки две-три и поприменять на практике. Тогда и будет видно, нужен ли ЮМЛ и кому, применим ли он в наших условиях и где. А жаловаться, что у нас этому не учат, стыдно. Представьте себя, меня никто не учил, как стать аналитиком. И за что зарплату платят?... Кто хочет - тот делает.

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

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

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

В теории все хорошо, а в практике, к сожалению, все не так гладко. На практике приходится сталкиваться с гораздо бОльшими трудностями, чем те, которые описаны в книге. И нужно не только уметь правильно применять полученные из книг знания, но и уметь подстраиваться под ситуацию. В книгах этому не учат. Тут нужен опыт.

Гради Буч и Марк Фаулер очень опытные программисты, которые в своих книгах обобщили свой опыт. Я считаю что каждый программист, называющий себя программистом, должен их прочесть. Но только этого мало. Это лишь вершина айсберга. Как и у любого айсберга, основная его часть скрыта под водой. Эта подводная часть и есть - практика.

Да.

Применяю в течение последних 3 месяцев и обучаю этому коллег (руководителей проектов и отдел тестирования, завтра начну обучать отдел разработки).

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

Согласна, но это не имеет никакого отношения к собственно UML. Теория отличается от практики в любой деятельности. И в любой деятельности нужно проявлять гибкость. Так что это общая тема, и конкретно UML ей ничего не добавил и не убавил.

Это сообщение отредактировал(а) ida - 6.3.2006, 14:25

Эх, Pegas - и рад бы, да не могу согласиться. Для каждого отдельно взятого человека это было бы так, если бы он был в гордом одиночестве среди творческих развивающихся личностей. Но когда такая вот леность становится всеобщей, то она начинает принимать едва ли не классовые черты и воспитывать профсоюзы, которые берутся отстаивать право на лень. Политически любое руководство на всех уровнях вынуждено с этим считаться, как садовник, подстригая телентливых личностей, что бы кустик коллектива в целом был красив и ровен. Так что либо приходится скакать с места на место в более развитые конторы, либо ровняться на середняк и буксовать.

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

Нет, людская лень, нежелание развиваться - это не столько частная проблема, сколько коллективная и один решивший её локально - всё равно в поле не воин...

Сейчас вот читаю "Peopleware" - там всё подтверждается - по тестам разница в производительности труда программистов, работающих в одной конторе, не превышает 20% - т.е. всё равно полюбому действует уравниловка, заставляя тебя быть "как все" - даже в успешных вроде бы конторах...

Се ля ви, опять ты здесь со своей политикой.....
А разница в 20% - не потому, что все вокруг дураки, а именно потому, что в связке люди работают и каждый зависит от другого. Да и коллектив подбирают не от балды, и чтобы он мог вместе работать, как одна команда. Если у них будет производительность сильно разной - не смогут.

ИМХО Се Ля Ви, ты заморочился. Пытаешся к большему приложить малое, а к малому - большее. Везде свои законы.

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

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

Мой опыт говорит, что это во многом разрекламированная вещь. Почему же все делают UML (Oracle - JDeveloper, Rational, Together, Sun - Java Enterprise Studio)? Потому что аналитики требуют наличия в портфолио компании UML. При чем время, когда за UML просили большие деньги, уже уходят. Оракл раздает его с JDeveloper, Sun теперь раздает его с Netbeans (И студию тоже сделали бесплатной). Цель - привлечь клиентов, создать community.

Как много изменилось за 3 года, да? ;)


Потому что UML - это удобно.

Это сообщение отредактировал(а) ida - 14.5.2008, 17:11

  

Ну в общем, есть такое. ))

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

И даже для небольших проектов я часто просто не могу себя заставить писать код, пока хотя бы на листочке не набросаю несколько диаграмм. Я начал мыслить UML`ом, понимать задачу в терминах UML`а. Даже в качестве документации предпочитаю UML-диаграммы разным средствам типа javadoc (если, конечно, они есть).

Однако проблемы с актуализацией (т.е. изменением диаграмм в соответствии с изменениями проекта в процессе разработки) всё-таки остались...

Большая часть «геморроя» и как правило провалов, связана с плохой или отсутствующей модели.. Ну не сделали как надо анализ, не поняли что надо, как это работает и как должно работать.. Потом, реализация писалась на коленках.. Потому что, «самый главный» («постановщик») задумчиво глядя в даль, принимал решения одному ему известным принципом.. Программист, разработчик БД и т.д. просто не знают о чем речь.. каждый реализует «главное, что бы работало»..
В общем, конечно мало где используются реальное построение моделей.. А жаль :( 
Но это не есть хорошо… 

Прочитал все обсуждение, вот и мои пять копеек.
1. Несколько лет назад пришел к пониманию, что для эфективной работы в области написания ИС(информационных систем) необходим универсальный инструмент моделирования предметной области, потому что ошибки на этапе проектирования слишком дорого обходятся проекту.
2. Я не программист в полном смысле этого слова, я не знаю синтаксис не одного языка программирования, и уже никогда им не буду.
3. Много лет я занимаюсь вопросами анализа и написания ТЗ и остро ощущаю необходимость иметь универсальное средство общения с разработчиком и архитектором проекта.
4. Об UML'е много слышал и сейчас читаю Фаулера и понимаю, что мысли которыми я руководствуюсь, оказывается пришли в голову более умным людям, которые сумели формализовать свой подход к проектированию и анализу предметной области. 
И последнее, наличие машинных кодов и ассемблера, не исключают ООП и языков высокого уровня? Однако, рассматривать UML просто как надстройку над средой для разаработки ПО, где можно быстренько набросать диаграмм, потом быстренько побежать к заказчику утвердить, потом в Билдере или Студии быстренько сгенерить качественный код, быстренько его оттестить, получить бабки и на Канары  думаю слишком однобоко. 
Для меня основная цель использования UML'я - получение непротиворичивой(прозрачной), неперегруженой лишними деталями, понятной всем участвующим в разработке ИС - модели предметной области, однако, даже сам Фаулер говорит, что не надо думать, что диаграммы сами по себе позволят вам отделить "мясо" от "костей" - в этом и состоит искусство аналитика.
Где-то в обсуждении уже мелькала проблема коммуникации внутри команды разработчиков...когда приходит человек работать в проект, каждый вроде занят своим делом, дают ему кусок работы и документацию, которую без личных (много-)часовых бесед с тем кто общался с заказчиком и был, типа, постановщиком задачи просто НЕ РАЗОБРАТЬ, а у многих хватит терпения ходить за человеком и постоянно пытать:"А здесь что имелось в виду?А это что за объект о нем упоминается но ничего здесь не написано?" А тя все посылают у самих работы море - проект горит. А теперь подумайте, если бы проект был документирован в UML'е - у всех однозначное понимание нотаций, насколько проще было бы разобраться?

Необходимости коммуникации внутри группы это не отменяет.

Все это конечно здоровски хорошо, но реалии таковы что на UML и другие важные задачи заказчик не дает времени - а деньги нужны.
Вообщем последний пункт - и без него пока нормально справляемся и поддерживаем код в актуальном состоянии. А я кроме того вообще графическую информацию не воспринимаю и вообще не люблю работать со всем, что связано с графикой, даже если нарисованы 2 прямоугольника мне нужно обьяснить словами все, чтобы я понял. Да и вообще, если обьяснять все словами - то все гораздо легче понять. Меня все еще эти алгоритмы умиляют, их наверное в ВУЗАХ до сих пор рисуют - я когда учился никогда их не понимал, стоило обьяснить все словами, я запросто мог написать реализацию.
ЗЫ . Фаулера тоже читал.

Се ля ви, 

качество кода зависит только от программиста. Если он называет переменные a,b,n, плохо знает оптимизирующие конструкции языка, не использует конвенции - вот это действительно влияет на код.
так же не сложно представить структуру проекта на начальном этапе - грамотному специалисту. Проблемы начинаются тогда, когда заказчик начинает вносить изменения, в уже разрабатывающийся проект, когда какой-то код уже написан.

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


Это сообщение отредактировал(а) Torsten - 10.6.2008, 22:33

Такие решения не в компетенции заказчика.
Их принимает компания-разработчик (руководитель проекта, например).


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


Это не имеет отношения к UML 
Только к тому, кто разрабатывает модели.

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

Это сообщение отредактировал(а) ida - 10.6.2008, 22:25

ida, 

Кто тебе это сказал ? Ты работаешь ? Сколько ты видила и сопровждала проекты ?

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


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


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


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

VictorP, 

А ты не думал, что есть другие способы обмена информацией ? Почему-то у всех сразу только uml в голове. Я лично на 100% текстовое и табличное представление информации намного удобнее графического + реальное общение разработчиков во время разработки. В качестве обмена информации идеально подходит вики. Там можно описать и все возможные операции БД, интерфейсы, коды возратов, системы тестов, документацию для разработчика (архитектура) - все что угодно.

Это сообщение отредактировал(а) Torsten - 10.6.2008, 22:54

Думаю, немало   


Не знаю, как это в небольших поектах, но в больших - это совсем не так. У нас подобными задачами занимается десяток людей, которые к программированию отошения не имеют - бизнес-аналитики, solution architect (3 штуки в текущем проекте), отчасти product manager... Если наши тимлиды будут ещё и с заказчиком постоянно контактировать - лучше сразу повеситься. Конечно, контакт есть, и тимлиды принимают участие в этом котле - но это не их прямые обязанности.

Вполне допускаю, что в проектах, где объем позволяет иметь для всех этих ролей одного человека, такой подход сработает.


Для этого программист должен быть ещё и экспертом в предметной области, т.е. проработать в ней (причем в бизнес-части!) не менее пяти лет. Нереально.


Тут ты прав. UML, конечно, универсален, но отнюдь не всегда оптимален.

Для справки: ida - девушка   

Дискусия несколько отклонилась от темы необходимости UML'я или его ненужности, но всеравно интересно 

Полностью согласен, с собеседником ida, а допустим проект, где Заказчик вместе с постановщиком(подрядчиком) составляют ТОЛЬКО требования к ПО, подрядчик пишет ТЗ, а реализацию пишет третья контора на условиях конкурса - вам не знакомы? Скока не работал с заказчиками, ему глубоко филолетово будешь пользоваться ты UML' или опишешь все в виде "сочинения" на вольную тему, лишь бы он тебя понял.
UML выходит на первое место в тех проектах, где с заказчиком общается аналитик, потому что есть не мной сформулированное правило - реализатор не может поставить себе качественное ТЗ, т.к. мыслит низкоуровневыми категориями, что не позволяет ему взглянуть на проект "сверху".

Позвольте не согласиться и с этим. Время выполнения задачи должно соответствовать качеству исполнения продукта, если проанализировав предметную область, союз трех - аналитик, архитектор и РП(руководитель проекта) приходят к мнению, что реализовать такой проект КАЧЕСТВЕННО, в заданный срок НЕВОЗМОЖНО, то и заказчик об этом должен занать. И дальше сам принимать решение, иначе - ПРОВАЛ НЕМИНУЕМ, что подорвет вашу репутацию и уменьшит кол-во ваших постоянных клиентнов("Сарафанное радио" - сам понимаешь). А уж убедить заказчика, что лучше вас это никто не сделает - это прямая задача сотрудников, которые за это отвечают .

Мы здесь, шо, априори, решили, шо аналитик у нас, так "вышел погулять", а вот программисты, все сплошь как один корифеи? Я шо то такой точки зрения здесь не слышал. Каждый должен заниматься своим делом, для небольшого проекта можно все вообще объединить в одном лице, а вот при серьезном проекте, да еще и команде разработчиков с 10 работающих над проектом, без нормального распределения обязанностей вопрос не решается в нормальные сроки и с приемлимым качеством. Поэтому и ответственность на аналитике немалая и требования к нему "не детские" в серьезных проектах.

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

Это просто Ха-ха, во-первых, если модель предметной области построена грамотно, то уточнения ее, будут только улучшать конечный продукт органично вливаясь в общую концепцию, а если нет, то это серьезный риск получить неудачную - нерасширяемую реализацию, это действительно профессионализм, только профессионализм АНАЛИТИКА.

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

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

А спорить можно хоть до укакашивания - пускай спорят те, у кого *** короткая.

batigoal, 

Я по возрусту вижу, что мало.


Я тоже не говорил, что это их прямые обязанности. Однако если они принимать участия не будут - будет полная неразбериха. Программирование процесс сложный, и если не зная как то или иное будет реализовыватся - получится полный абзац.


Для этого надо с ней познакомится, и определится с закачкиком чего он хочет. Эта занимает обычно не меньше месяца.


Цитата(Torsten @  10.6.2008,  23:40 )

Я знаю, это вообще я отвечал VictorP, а не ей.

boloeng, 
Не убедил, сказанный слова не заменяет реальных условий и проектов. Но спорить я с тобой не буду, ты лучше в теории плаваешь. Я бы с тобой поспорил год назад, когда Фаулера почитал, однако после того как прочитал - я все из своей головы выкинул за ненадобностью.
Единственное, что :

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


ida, 

У меня уже есть опыт, я знаю и делаю все это в реальной жизни, а не живу сказками.
Из тобой сказанного я просто понимаю, что тебе нечего мне ответить, в отличии от boloeng, например.


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

Это сообщение отредактировал(а) Torsten - 11.6.2008, 17:31

Вот с этого и надо было начать 

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