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

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, спасибо за делёжку опытом

Спору нет.