-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Илья2
Guest
2kvn:
процесс как я понимаю есть в RUP - т.е. это принцип итераций, ориентация на прецеденты и ориентация на архитектуру.
http://nemilya.by.ru/erobot там я пытался нарисовать пояснения к программе (почтовый робот) на uml.
Как я его делала - проектировал несколько дней, т.е. рисовал на бумаге только uml, т.е. диаграмы классов, взаимодействий, потом за один день запрограммировал. (в реальной задаче этот робот только часть системы, он получает логин, пароль и CSV-данные проверяет их, и складирует в репозиторий и т.д.)
это можно сказать был мой первый эксперимент по uml+php после этого было еще несколько проектов, и по результатам я могу сказать, что проектирование на uml помогает.
ну по крайней мере я так думал, ну и на сайте xprogramming.ru есть фраза что "не используем UML или выбрасываем UML диаграмы"
методология проектирования, т.е. это методология выделения классов объектов и т.п. , т.е. это - CRC и т.д. (или я не прав?)
процесс как я понимаю есть в RUP - т.е. это принцип итераций, ориентация на прецеденты и ориентация на архитектуру.
у меня есть тоже страничка
http://nemilya.by.ru/erobot там я пытался нарисовать пояснения к программе (почтовый робот) на uml.
Как я его делала - проектировал несколько дней, т.е. рисовал на бумаге только uml, т.е. диаграмы классов, взаимодействий, потом за один день запрограммировал. (в реальной задаче этот робот только часть системы, он получает логин, пароль и CSV-данные проверяет их, и складирует в репозиторий и т.д.)
это можно сказать был мой первый эксперимент по uml+php после этого было еще несколько проектов, и по результатам я могу сказать, что проектирование на uml помогает.
Mammoth
Guest
2 Илья2:
Формулируя своими словами, формализация - процесс избавления от вышеописанных недостатков в описании системы. За более детальными или точными определениями рекомендую обратиться к энциклопедиям. Вот, посмотри, что я пока нашел в энциклопедиях Кирилла и Мефодия:
Объясню по мере возможности. Любой естесственный язык имеет следующие недостатки, являющиеся причиной субъективизма: избыточность, неточность, неполнота, неоднозначность. Именно наличие этого факта является причиной сложности написания систем машинного перевода. Для избавления от вышеописанных недостатков при документировании систем используется формальное описание.
Формулируя своими словами, формализация - процесс избавления от вышеописанных недостатков в описании системы. За более детальными или точными определениями рекомендую обратиться к энциклопедиям. Вот, посмотри, что я пока нашел в энциклопедиях Кирилла и Мефодия:
На остальные вопросы-утверждения я отвечу попозже, ладно? Кушать больно хочется... ;-)
AlexKill
Guest
Добрый день!
Я конечно новичок в это теме, но свои пять копеек втавлю.
Дело в том, что во многих компаниях на Западе(например у нас) написание кода состовляет около 30%, все остальное уходит на проектирование (25%), тестирование(25%) и документацию(20%).
Причем все это должно делатся так, как буд-то ты завтра собираешься заболеть и другой человек с фирмы вместо тебя смог разобраться с проектом и ответить на вопросы клиента.
В таких случаях УМЛ упрощает жизнь. Так что нужно рассматривать это не толкьо как переходник Проект-Исходный код, а как Планироване-Проект-Функционалитет-Документация или что-то в этом роде.
З.Ы. Реальная повторяющаяся ситуация. Я что-то в каком-то проекте как-то сделал. Через год возникает вопрос типа
- правильно это работает
- использует ли это что-то
- можно ли оптимизировать
- а давайте для нового проекта сделаем как в старом и т.д
И начинается перерывание искходного кода, ведь планирование проекта отсутсвует как клас.
Во время долгой работы на одном мести и введения множества проектов, это приводит к потере времени и осознавания нужности УМЛ или его аналога.
Я конечно новичок в это теме, но свои пять копеек втавлю.
Дело в том, что во многих компаниях на Западе(например у нас) написание кода состовляет около 30%, все остальное уходит на проектирование (25%), тестирование(25%) и документацию(20%).
Причем все это должно делатся так, как буд-то ты завтра собираешься заболеть и другой человек с фирмы вместо тебя смог разобраться с проектом и ответить на вопросы клиента.
В таких случаях УМЛ упрощает жизнь. Так что нужно рассматривать это не толкьо как переходник Проект-Исходный код, а как Планироване-Проект-Функционалитет-Документация или что-то в этом роде.
З.Ы. Реальная повторяющаяся ситуация. Я что-то в каком-то проекте как-то сделал. Через год возникает вопрос типа
- правильно это работает
- использует ли это что-то
- можно ли оптимизировать
- а давайте для нового проекта сделаем как в старом и т.д
И начинается перерывание искходного кода, ведь планирование проекта отсутсвует как клас.
Во время долгой работы на одном мести и введения множества проектов, это приводит к потере времени и осознавания нужности УМЛ или его аналога.
fisher
накатила суть
хорошие дискуссии стали возникать, оно неожиданно и приятно 
. стал я тут фаулера почитывать, краткий курс по UML. скажу честно, сам никогда этот подход не использовал, поскольку и не знал, как, и до сих пор пока до конца не понимаю, зачем это именно мне, или моей компании в целом. "здесь" привыкли работать, не так как "там". и не потому, что тут кто-то умнее или наоборот. методы работы (стадии разработки проекта, штатное расписание и проч.) - являются функцией "системы", "среды". сколько вы сможете привести примеров нашего родного программного продукта, который делали бы десятки людей одновременно? в котором функционированию "процесса" уделялось бы такое внимание, чтобы находились люди, желающие формализовать даже сам процесс? и сколько из этих проектов имеет отношение к веб-технологиям, и уж тем более, к php? вот такие пара центов. у нас нанимают людей по одному принципу - чтоб человек был вменяем и чтоб человек был хороший. ну нет у нас _индустрии_, нет её.
. стал я тут фаулера почитывать, краткий курс по UML. скажу честно, сам никогда этот подход не использовал, поскольку и не знал, как, и до сих пор пока до конца не понимаю, зачем это именно мне, или моей компании в целом. "здесь" привыкли работать, не так как "там". и не потому, что тут кто-то умнее или наоборот. методы работы (стадии разработки проекта, штатное расписание и проч.) - являются функцией "системы", "среды". сколько вы сможете привести примеров нашего родного программного продукта, который делали бы десятки людей одновременно? в котором функционированию "процесса" уделялось бы такое внимание, чтобы находились люди, желающие формализовать даже сам процесс? и сколько из этих проектов имеет отношение к веб-технологиям, и уж тем более, к php? вот такие пара центов. у нас нанимают людей по одному принципу - чтоб человек был вменяем и чтоб человек был хороший. ну нет у нас _индустрии_, нет её.Mammoth
Guest
Что такое система? Общее понятие или какое-то ПО? Что означает выделение? Без ответа на эти вопросы я не смогу понять смысл высказывания "В модели системы такого объекта не существует."... ;-(
Кстати, что за термин - бизнес-моделирование? Следует ли его понимать как "создание модели бизнес-процессов предприятия"?
А как по твоему, предприятие - это система или нет?
Типичный пример неформализованного ответа. Типа диалога:
- Что такое дорога?
- Ну... это там где ездят машины...
- А где ездят машины?
- По дороге...
В целом, я конечно, догадался, что такое "реалии", но "бумагу" я не одолел... Зачем делать систему по "бумаге", если не известно, что это такое и откуда оно берется? ;-)
Да? С каких это пор моделирование стало вестись на объектно-ориентированном языке? Ты случайно не запутался? Твоя цепочка доказательств что-то мне не очень понятна...
Mammoth
Guest
Очень сильно зависит от того, что понимать под "нашим" и "программным продуктом". Взять хотя бы космические программы... Хотя их не афишируют...
Или хотя бы то, что по слухам из непроверенных источников, в Майкрософте - проценнтов 80, выходцы из бывшего СССР + индусы, китайцы, и пр. Так что может быть, можно и продукты Майкрософта нашими называть? ;-)
Borman
Guest
Ух сколько намолотили за 1 день !
Богатого практического опыта управления проектами у меня нет, но я обучался и стажировался в серьезной компании (TelesensKSCL Ukraine) и интересовался опытом управления проектами в других компаниях.
Project Manager не должен заниматься проектированием архитектуры и дизайна системы, это прямая обязанность системного аналитика. PM планирует объем работ, колиество ресурсов, стоимость, разрабатывает план-график и управляет процессом разработки. UML я изучал в рамках курса PM и самостоятельно, будучи ранее девелопером.
UML высоко ценю как средство универсальное средство проектирования объектно-ориентированных систем. Сколько уже было создано различных методологий, что можно было умом поехать пытаясь разобраться в каждой из них. UML стал стандартом и снял проблему непонимания.
UML в первую очередь полезен для реализации больших проектов, где в разработке участвуют много людей и полностью структуру системы знают только ведущие специалисты. Остальным разработчикам знать ее не обязательно, они обязаны знать только тот кусок программы, который они непосредственно разрабатывают и точки взаимодействия с другими частями системы. Объектная модель системы (на UML) в таком случае оказывается весьма кстати.
Чем полезен UML при разработке мини проектов :
лучше изложить модель системы на бумаге (на экране) чем постоянно держать его в голове - это экономит время при кодировании (написании кода программы), позволяет видеть всю картину вцелом, связи между модулями программы и т.д.
К тому же удобнее рисовать структуру классов в виде схемы, а потом ее сгенерить, чем долбить руками, мотаясь по файлам и тексту программы выискивая названия связанных классов, названия методов и полей.
Насчет XP и UML : В книге "Практическое руководство по ХР" пишут что можно юзать UML-диаграмки если это упростит или ускорит работу, не нужно рисовать ненужные диаграммы. А если нужная диаграмма стала уже не нужна, то ее нужно выбросить
Вообще ХР вещь эффективная, только есть одна проблемка:
организация коллектива. ХР-команда должна быть очень квалифицирована и эффективно взаимодействовать между собой. На ХР переходят в течение года а то и больше. Если в команде есть неквалифицированные кадры или ранее не был налажен механизм коллективного техпроцесса, то попытки применения ХР не дадут ожидаемого результата.
В RUP все несколько по другому - управлением проекта и разработкой архитектуры и дизайна занимаются профессионалы, а кодирование и тестирование можно поручить менее квалифицированным кадрам. Получается, что каждый квалифированно занимается своим делом и не распыляется на другие дела.
Из опыта работы одной компании со слов девелопера : "Аналитики рисуют нам диаграммы, только мы все равно делаем все по своему. Получается, что аналитики у нас только бумагу марают."
У них явно прослеживается конфликт в том, что аналитики разрабатывют дизайн системы, не владея профессионально навыками программирования на данном языке. Поэтому, аналитики или должны научиться программить или дизайн системы должны разрабатывать сами девелоперы. Аналитики при этом должны ограничиться только разработкой архитектуры: UseCase, описанием системы и общей структурой.
Че-то меня понесло....
Буду закругляться...
Богатого практического опыта управления проектами у меня нет, но я обучался и стажировался в серьезной компании (TelesensKSCL Ukraine) и интересовался опытом управления проектами в других компаниях.
Project Manager не должен заниматься проектированием архитектуры и дизайна системы, это прямая обязанность системного аналитика. PM планирует объем работ, колиество ресурсов, стоимость, разрабатывает план-график и управляет процессом разработки. UML я изучал в рамках курса PM и самостоятельно, будучи ранее девелопером.
UML высоко ценю как средство универсальное средство проектирования объектно-ориентированных систем. Сколько уже было создано различных методологий, что можно было умом поехать пытаясь разобраться в каждой из них. UML стал стандартом и снял проблему непонимания.
UML в первую очередь полезен для реализации больших проектов, где в разработке участвуют много людей и полностью структуру системы знают только ведущие специалисты. Остальным разработчикам знать ее не обязательно, они обязаны знать только тот кусок программы, который они непосредственно разрабатывают и точки взаимодействия с другими частями системы. Объектная модель системы (на UML) в таком случае оказывается весьма кстати.
Чем полезен UML при разработке мини проектов :
лучше изложить модель системы на бумаге (на экране) чем постоянно держать его в голове - это экономит время при кодировании (написании кода программы), позволяет видеть всю картину вцелом, связи между модулями программы и т.д.
К тому же удобнее рисовать структуру классов в виде схемы, а потом ее сгенерить, чем долбить руками, мотаясь по файлам и тексту программы выискивая названия связанных классов, названия методов и полей.
Насчет XP и UML : В книге "Практическое руководство по ХР" пишут что можно юзать UML-диаграмки если это упростит или ускорит работу, не нужно рисовать ненужные диаграммы. А если нужная диаграмма стала уже не нужна, то ее нужно выбросить
Вообще ХР вещь эффективная, только есть одна проблемка:
организация коллектива. ХР-команда должна быть очень квалифицирована и эффективно взаимодействовать между собой. На ХР переходят в течение года а то и больше. Если в команде есть неквалифицированные кадры или ранее не был налажен механизм коллективного техпроцесса, то попытки применения ХР не дадут ожидаемого результата.
В RUP все несколько по другому - управлением проекта и разработкой архитектуры и дизайна занимаются профессионалы, а кодирование и тестирование можно поручить менее квалифицированным кадрам. Получается, что каждый квалифированно занимается своим делом и не распыляется на другие дела.
Из опыта работы одной компании со слов девелопера : "Аналитики рисуют нам диаграммы, только мы все равно делаем все по своему. Получается, что аналитики у нас только бумагу марают."
У них явно прослеживается конфликт в том, что аналитики разрабатывют дизайн системы, не владея профессионально навыками программирования на данном языке. Поэтому, аналитики или должны научиться программить или дизайн системы должны разрабатывать сами девелоперы. Аналитики при этом должны ограничиться только разработкой архитектуры: UseCase, описанием системы и общей структурой.
Че-то меня понесло....
Буду закругляться...
fisher
накатила суть
2Mammoth: эээ... мы гооврим о веб-технологиях, о пхп, или так, за жизнь, о непроверенных данных? если последнее - я ошибся насчет хорошей дискуссии
я не против теоретизирования, но на этом форуме кажется нет настоящих теоретиков, которые могли бы поучаствовать в дискуссии. поэтому меня интересует именно практическая область. кто-то из присутствующих работает в майкрософт? или состоит в каком-то супер-отделе института космических исследований и пишет грандиозную систему управления на пхп?
именно поэтому мне очень хотелось бы послушать людей, действительно протащившихся от UML и начавших применять это добро в своей работе (не дипломной, работе, за которую им денег платят.
я не против теоретизирования, но на этом форуме кажется нет настоящих теоретиков, которые могли бы поучаствовать в дискуссии. поэтому меня интересует именно практическая область. кто-то из присутствующих работает в майкрософт? или состоит в каком-то супер-отделе института космических исследований и пишет грандиозную систему управления на пхп?
именно поэтому мне очень хотелось бы послушать людей, действительно протащившихся от UML и начавших применять это добро в своей работе (не дипломной
, работе, за которую им денег платят.webdeveloper
Guest
Я за два с половиной года работы здесь ни разу не делал ничего связанного с UML. Тут наверное три четверти людей и не знают о том, что это такое. Хотя это тоже сильно зависит от того в какой компании ты работаешь. У нас это не принято, но если пойдти в контсалтеры то думаю что там это будут одним из важных критериев.
Здесь нет как такового рынка работы на РНР. Около 80 процентов рынка занимает ASP. Остальное это JSP + JavaServlets. Тем кто пишет на ASP ни о каком ООП думать не приходится. На джаве это требуется. но опять таки джава болле распространена в крупных компаниях. В среднего размера фирмах и небольших компаниях на джаве писать не выгодно. Это примерно как на РНР или на С++. На С++ конечно круче, но зато на РНР ты два проекта успеешь написать за это время.
На мой взгляд использование UML никак не долджно быть связано со стоимосьтью проекта. Это просто еще один способ организовать работу. Иногода он очень полезен. Иногода он абсолютно не нужен. It depends.
Ну клиенты и их знания тут абсолютно не причем. Ты же когда идешь ко врачу не должен знать все тонкости медицины. Так и в програмировании. Не нужно забывать что мы все работаем не для себя а для заказчика. Если бы заказчик все знал сам и все умел то он бы делал сайты сам.
Закзчик это всего лишь человек. Он может чего то не знать или в чем то заблуждатся. Ему можно все толково объяснить. Как правило, если заказчик достаточно умен для того что бы интересоватся, "а используете вы UML или нет" - то он безусловно сможет понять зачем это нужно. Если заказчик далек от этого и даже не хочет в это вникать то незачем его загружать такими "интимными" подробностями. Ему абсолютно безразлично, как именно вы сделали сайт. Главное что бы все кнопочки были слева, или все заголовки были бы определенного шрифта.
UML на мой взгляд это не столько язык, сколько просто стандартный способ визуально отображать струтуру проекта. При этом он наверное не самый удачный, но зато стандатный. Он не зависит от языка на котором пишется проект и это делает его еще болле привелкательным. Можно написать проект на С++ а потом используя UML переписать это все на джаву или С# например. Кроме того, это очень удобный способ организовать работу в команде. Если все члены команды умеют читать эти диаграммы то тогда нет проблем - выдай каждому по копии и вперед.
При этом применение UML при разработке гостевой книги, на мой взгляд смешно. Я ее бстрее напишу чем диаграмму составлю.
Точно так же, на мой взгляд, не правильно говорить об удорожании стоимости проекта за счет применения UML. UML позволяет более глубоко продумать структуру проекта. Поэтому брать за его использование дополнительные деньги это все равно, что брать деньги с клиента за то что ты не просто делаешь что ему нужно, а делаешь это хорошо и думаешь о том что ты делаешь.
STAH
Guest
По-поводу "там" - "здесь". Из того, что я услышал от моих профессоров из недалекого прошлого и моих нынешних коллег, американской школы UML не существует. Развитие данного языка происходит за счет европейских специалистов. Самые лучшие книги по UML, кот. я прочитал были написаны французскими авторами. Четыре года назад, мой профессор по UML очень граммотно научил меня использовать UML в моих проектах (в ту эпоху о web программировании особо не говорили). Причем предмет по УМЛ был одним из основопологающих (в моем дипломе написано крупными буквами, что я - Analyste-Programmeur = (Программист-Аналитик ?)). В итоге, как выразился тут товарищ из Германии, бОльшая часть разработки ПО тратится на ее концептуальное моделирование. Кодингом же будет заниматься бедняга, которого заложат бумагамии и очень симпатичным deadline'ом. За свою работу он получит гроши, по сравнению с коммандой "концепторов" и "аналистов", умеющих красиво выражатся на словах и на UML. В Америке и России, я так понимаю, такого беспредела нет
По-поводу написания мною uml2web. Основываюсь я не на собственном опыте, а на опыте моих коллег, кот. использовали UML в нескольких web проектах. Книги я тоже использую. Без них не обойтись.
Вот тякъ.
По-поводу написания мною uml2web. Основываюсь я не на собственном опыте, а на опыте моих коллег, кот. использовали UML в нескольких web проектах. Книги я тоже использую. Без них не обойтись.
Вот тякъ.
Илья2
Guest
2Mammoth
, т.е. смысл в том что-бы вот эта созданная программная система позволила бы более эффективно выполнять бизнес-функции, ведь он мог бы работать со счетами (т.е. без программной системы), но это было бы медленнее
И для этих задач может использоваться UML, но также есть другие методологии, например IDEF0.
Да, и спасибо за прояснение слова "формализовать", с этой точки зрения IDEF0 более формализует чем UML
Да в данном контексте говорится о программной системе. Т.е. кассир работает с программной системой, и в то же время выполняет функции бизнес системы
, т.е. смысл в том что-бы вот эта созданная программная система позволила бы более эффективно выполнять бизнес-функции, ведь он мог бы работать со счетами (т.е. без программной системы), но это было бы медленнее да, бизнес-моделирование - это создание модели бизнес процессов предприятия.
И для этих задач может использоваться UML, но также есть другие методологии, например IDEF0.
Система, но просто в литературе по UML слово "система" употребляется в контексте программного продукта.
ладно, оставим это, я еще не "guru", поэтому могу вносить "непонятки", надо читать классиков, Буча, Джекобсона, Рамбо, Крэга Лармана, Филипа Крэтчена, Фаулера.
Да, и спасибо за прояснение слова "формализовать", с этой точки зрения IDEF0 более формализует чем UML
Илья2
Guest
2fisher:
мне кажется веб технологии можно было бы эффективно перевести на UML рельсы, можно пару программистов, пару дизайнеров, одного архитектора и одного менеджера, вот и будет 6 человек, и если все сделать и все они профессионалы, то можно было бы очень повысить качество выходного продукта (конечно больше касаясь программной части) и скорость изготовления.
Илья2
Guest
2webdeveloper:
(помоему так всегда и происходит)
стоит ли брать дороже за здание с фундаментом по сравнению со зданием без фундамента?
вполне возможно что у 1 этажного дома, будет 3-х этажный фундамент.
тогда это получится в 4 раза дороже.
так же и UML и без UML (под UML я имею ввиду объектно-ориентированное программирование, что мне кажется сложно сделать без UML моделей). Моделирование и проектирование продумывает "фундамент", и на это надо больше усилий, чем просто написать программу которую надо заказчику. Просто если поступить по последнему варианту (просто быстро написать программу), то она (программа) просто не будет удовлетворять другим критериям - масштабируемость, гибкость, надежность. Т.е. потребуется затратить бОльше усилий для ее изменения, чем если бы она (программа) была хорошо продумана и спроектирована.
это конечно так, но если потом надо будет что-то изменить, и для этого окажется что быстрее все переписать заново
(помоему так всегда и происходит
)а вот с этим не согласен, пример:
стоит ли брать дороже за здание с фундаментом по сравнению со зданием без фундамента?
вполне возможно что у 1 этажного дома, будет 3-х этажный фундамент.
тогда это получится в 4 раза дороже.
так же и UML и без UML (под UML я имею ввиду объектно-ориентированное программирование, что мне кажется сложно сделать без UML моделей). Моделирование и проектирование продумывает "фундамент", и на это надо больше усилий, чем просто написать программу которую надо заказчику. Просто если поступить по последнему варианту (просто быстро написать программу), то она (программа) просто не будет удовлетворять другим критериям - масштабируемость, гибкость, надежность. Т.е. потребуется затратить бОльше усилий для ее изменения, чем если бы она (программа) была хорошо продумана и спроектирована.
fisher
накатила суть
2Илья:
простите, но кажется - это больше из другой области. а вот я не вижу в этом никакого смысла пока. если программистов 2-3 - все проблемы могут быть решены в "обычном" режиме. но при этом я действительно хочу от любой методологии взять самое лучшее, чтобы повысить качество и эффективность процесса.
2STAH:
начет кодеров и аналистов - это большая проблема, тут уже столько копьев сломано, со всех сторон обиды - лучше это не поднимать
мне интересно другое. вот я разобравшись в предметной области получил у себя в голове картину проекта, я знаю ЧТО будет делаться, и знаю, КАК - т.е. я хорошо знаю также и технологии, на которых будет разработан продукт (иначе я - хреновый аналист, верно?). и тут происходит вещь мне не понятная (либо я не совсем Вас понял).
вместо того, чтобы сесть и грамотно запрограммить ядро проекта, может, с остальной часть - понаставничать над теми, кого Вы называете кодерами - я сажусь и рисую какие-то схемки, чтобы - внимание - потом отдать это на программирование другим менее квалифицированным людям. мне-то всё уже понятно, но мне теперь это надо ещё разрисовать, объяснить и передать(!) другому. я предпочел бы наставничество. качество кода для меня не менее важно чем качество идеи, поскольку на повторном использовании читабельного и качественного кода я выигрываю больше. имхо. вот и растолкуйте мне, где я не прав. хотя это и не совсем про UML, но около.
да, и по-прежнему жду продолжения текста
простите, но кажется - это больше из другой области. а вот я не вижу в этом никакого смысла пока. если программистов 2-3 - все проблемы могут быть решены в "обычном" режиме. но при этом я действительно хочу от любой методологии взять самое лучшее, чтобы повысить качество и эффективность процесса.
2STAH:
начет кодеров и аналистов - это большая проблема, тут уже столько копьев сломано, со всех сторон обиды - лучше это не поднимать
мне интересно другое. вот я разобравшись в предметной области получил у себя в голове картину проекта, я знаю ЧТО будет делаться, и знаю, КАК - т.е. я хорошо знаю также и технологии, на которых будет разработан продукт (иначе я - хреновый аналист, верно?). и тут происходит вещь мне не понятная (либо я не совсем Вас понял).
вместо того, чтобы сесть и грамотно запрограммить ядро проекта, может, с остальной часть - понаставничать над теми, кого Вы называете кодерами - я сажусь и рисую какие-то схемки, чтобы - внимание - потом отдать это на программирование другим менее квалифицированным людям. мне-то всё уже понятно, но мне теперь это надо ещё разрисовать, объяснить и передать(!) другому. я предпочел бы наставничество. качество кода для меня не менее важно чем качество идеи, поскольку на повторном использовании читабельного и качественного кода я выигрываю больше. имхо. вот и растолкуйте мне, где я не прав. хотя это и не совсем про UML, но около.
да, и по-прежнему жду продолжения текста
Crazy
Developer
Это не проблема UML, а отголоски известной болезни под названием "маниакальное проектирование". Им должен переболеть каждый, кто знакомиться с формальными методиками проектирования. У большинства быстро вырабатывается иммунитет, но у некоторых переходит в хроническую фазу.
Признаками хронической стадии "маниакального проектирования" являются попытки составить ВСЕ возможные типы диаграмм для КАЖДОГО этапа проекта. В этом случае для гостевой книги в две страницы кода порождается 30-40 страниц диаграмм и работа занимает в 5-6 раз больше времени.
Признаком выработанного иммунитета является понимание того, что нужно составлять и поддерживать только необходимый минимум диаграмм. Для той же гостевой книги это usecase и, возможно, диаграмму классов для отображения структуры БД.
"Я напишу лучше без проектирования" срабатывает только на типовых задачах, которые настолько разжеваны, что в них вообще не осталось неясных мест.
Но даже для тривиальных задач UML может быть использования для документирования принятых решений, ибо даже тривиальщину можно сделать очень по-разному.
Crazy
Developer
UML не навязывает вообще никакого стиля проектирования.
Есть такое ощущение.
В случае использования UML это будет 3-4 абзаца с описанием usecase, еще столько же -- описание нефункциональных требований и диаграмма классов для описания структуры базы. Та же задача -- тот же объем проектных материалов.
Почему?
fisher
накатила суть
думаю, webdeveloper имел ввиду не отстутствие проектирования вообще, а отсутствие проектирование в навязываемом UML стиле. кажется, мы тут путаем проектирование и UML. для гостевой можно написать текст на 1 страничке + ERсхема. это не показательный и имхо очень неудачный пример в контексте UML.