что такое UML?
Что такое ООП - знаешь?
Если да, то представь себе, как бы ты схематично (скажем, на доске) изображал классы/объекты, их взаимоотношения, порядок их взаимодействия и т. д. UML удобно изучить не сам по себе, а как иллюстрирующее средство. Например, к design pattern.
Если да, то представь себе, как бы ты схематично (скажем, на доске) изображал классы/объекты, их взаимоотношения, порядок их взаимодействия и т. д. UML удобно изучить не сам по себе, а как иллюстрирующее средство. Например, к design pattern.
т. е. - это навороченный интерфейс для создания алгоритмов программ?
или это язык программирования, или еще что ?
могу ли я пристроить это спользой для вебпрограмминга?
или это язык программирования, или еще что ?
могу ли я пристроить это спользой для вебпрограмминга?
могу ли я пристроить это спользой для вебпрограмминга?С таким уровнем интеллекта - конечно же, нет.
т. е. - это навороченный интерфейс для создания алгоритмов программ?UML = Unified Modeling Language. То есть это стандарт для рисования схемок. При желании можешь использовать хоть для рисования карты боевых действий.
или это язык программирования, или еще что ?
Посмотри здесь
http://en.wikipedia.org/wiki/Unified_Modeling_Language
Интересно что в украинской версии присутствует (другой) текст на русском.
http://en.wikipedia.org/wiki/Unified_Modeling_Language
Интересно что в украинской версии присутствует (другой) текст на русском.
UML - де факто стандарт в разработке ПО и уже становится стандартом в описании бизнес -процессов. Любой уважающий себя айтишник должен быть знаком с UML
уже становится стандартом в описании бизнес -процессовась?
UML -- это когда очень богатая фирма нанимает индуса, который рисует нахуй никому не нужные UML-диаграммы пол года, а потом его увольняет, потому что осознает свою ошибку.
Не бойтесь, индусов хоть и много, почти как китайцев, но без работы они не остаются.
Не бойтесь, индусов хоть и много, почти как китайцев, но без работы они не остаются.
ась?то что я сказал
могу ли я пристроить это спользой для вебпрограмминга?Есть один у меня такой любитель. Он устраивается в разные канторы за очень-большие-деньги и рисует там диаграммы "кто куда ходит". Потом когда надо писать, он съебывается и кидает кантору.
Думаешь, он индус? Не, он -- еврей!
Что такое ООП - знаешь?гы, я вот знаю, что это то самое, о котором у каждого свое, специальоне, специфическое представление
С таким уровнем интеллекта - конечно же, нетНу почему же нет....
Немного поботал какую то книгу по субжу...
Понял только одно, что это еще одно выдуманное людьми Г, призванное в идее упростить жизнь, но в реале ее только усложняющее....
Или может мне кто более доступно объяснит, какая польза может быть от набора правил рисования диаграмм?
Тем, что этими диаграммами можно обмениваться, и друг-другу показывать.
> какая польза может быть от набора правил рисования диаграмм?
Унификация мышления сотрудников. Полезная для бизнеса штука.
Унификация мышления сотрудников. Полезная для бизнеса штука.
нет, ну это то понятно... а при чем тут мой уровень интилекта?
и какой прок от диаграммирования всего и вся за безумне бабки (как было сказно вверху)?
и какой прок от диаграммирования всего и вся за безумне бабки (как было сказно вверху)?
прок такой , что если ты работаешь в команде - никто не будет ковырятся в твоем тексте , ты лишь показываешь артефакты своей работы ,такие как диаграммы, документашки и прочее, для того чтоб коллеги могли быстро и безошибочно вникнуть в то что ты сотворил.
что такое тексты, и что такое документашки?
Исходный код программы и документация к ней.
точно
часто в бизнес приложениях (хорошо написанных) в код смотреть гораздо удобнее, чем куда либо еще.
Конечно по-хорошему должен быть обзорный документ, где излагаются основные подходы. Этот документ, имхо, удобнее писать\читать на естественном языке, с некоторыми картинками.
Конечно по-хорошему должен быть обзорный документ, где излагаются основные подходы. Этот документ, имхо, удобнее писать\читать на естественном языке, с некоторыми картинками.
рисовать человечка на каждый чих в системе, имхо, это бред
современные IDE предоставляют достаточно удобные средства навигации по коду
дык никто тебя не заставляет рисовать чувака на каждый чих. УМЛ вообще не способен учитывать каждый чих, и создавался он не для этого, и используется не так. Строй диаграммы с той степенью подробности, которая нужна, чтобы ускорять процесс разработки, рефакторинга, добавления функциональностей и т.д. - чего тебе нужно, короче. Не надо доводить хорошую идею до абсурда.
Строй диаграммы с той степенью подробности, которая нужна, чтобы ускорять процесс разработки, рефакторинга, добавления функциональностей и т.д. - чего тебе нужно, короче.я так и делаю
Но тогда получается слишком узкое назначение UML -- только для разработчиков для оптимизации процесса кодирования.
для архитекторов и дизайнеров - чтобы разрабатывали
для кодеров - чтобы легче было разбираться, получив в руки частично готовый проект
для кодеров - чтобы легче было разбираться, получив в руки частично готовый проект
какая польза может быть от набора правил рисования диаграмм?ну как, сохранил в Розе, а распечатал в Visio. Чувствуешь теперь всю мощь UML?
много ли сейчас на рынке кодеров, рюхающих UML? и сколько они стоят?
читающих УМЛ - много
пишущих УМЛ - мало, но они и не нужны
пишущих УМЛ - мало, но они и не нужны
пишущих УМЛ - мало, но они и не нужныт.е. на язык написания диаграмм в принципе можно забить ?
тебе не кажется, что одно дело - заботать язык в достаточной мере, чтобы читать диаграммы, а совсем другое дело - заботать так, чтобы мочь их писать?
если ты можешь это понять, то ты можешь это воспроизвести...
иначе ка бы тогда происходило обучение человека грамоте?
иначе ка бы тогда происходило обучение человека грамоте?
например, французские и немецкие тексты я читаю со словарем с разумной скоростью и высоким процентом понимания, а пишу на этих языках с очень низкой скоростью и большим количеством ошибок. Не говоря уже о таких языках, как SQL, латинский, фортран или польский, которые я медленно, но стабильно и без проблем читаю, а воспроизвести не могу вовсе.
> если ты можешь это понять, то ты можешь это воспроизвести...
совсем нет. Простой пример - иностранный язык - понимать чужую речь довольно быстро учаться, а вот говорить - быстро, грамотно и без акцента - получается только у очень и очень немногих и после длительной подготовки.
ps
Мощность задач разная - при чтении - задача закрытая (результат можно проверить) - нам плохо известное надо перевести в хорошо известное - соответственно можно использовать коррекцию ошибок,
при написании - задача открытая(результат проверить нельзя)- надо хорошо известное перевести в плохо известное - применять коррекцию ошибок не получается.
совсем нет. Простой пример - иностранный язык - понимать чужую речь довольно быстро учаться, а вот говорить - быстро, грамотно и без акцента - получается только у очень и очень немногих и после длительной подготовки.
ps
Мощность задач разная - при чтении - задача закрытая (результат можно проверить) - нам плохо известное надо перевести в хорошо известное - соответственно можно использовать коррекцию ошибок,
при написании - задача открытая(результат проверить нельзя)- надо хорошо известное перевести в плохо известное - применять коррекцию ошибок не получается.
пример с инязом неуместен...
ибо в UML да и других комповских зыках нет вского рода склонений, падежей, времен и т.д.
т. е. язык одномерный.
а именно - просто текстовая (графическая) форма записи действия.
Поэтому - воспроизводится это все гораздо легче, чем заучивание 9 вариантов обюознаения себя в японском языке (к примеру)
А отсюда вывод, что если у того, кто читае диаграмы есть голова на плечах - то он может их и воспроизвести...
т.е. максимус, что надо - это просто иметь представление о том, что и как обознаается...
Т.к. ИМХО для лубого компового языка тебе достаточно иметь "словарь" синтаксиса, и ты можешь писать на этом языке...
Конечно, при условии, что есть еще и "Нтилект")
ибо в UML да и других комповских зыках нет вского рода склонений, падежей, времен и т.д.
т. е. язык одномерный.
а именно - просто текстовая (графическая) форма записи действия.
Поэтому - воспроизводится это все гораздо легче, чем заучивание 9 вариантов обюознаения себя в японском языке (к примеру)
А отсюда вывод, что если у того, кто читае диаграмы есть голова на плечах - то он может их и воспроизвести...
т.е. максимус, что надо - это просто иметь представление о том, что и как обознаается...
Т.к. ИМХО для лубого компового языка тебе достаточно иметь "словарь" синтаксиса, и ты можешь писать на этом языке...
Конечно, при условии, что есть еще и "Нтилект"
)естественный язык ты тоже воспроизведешь вопрос, сколько у тебя потребуется времени, чтобы прочитать предложение на японском, а сколько, чтобы написать?
В отношении олбсуждаемой темы, сколько секунд тебе понадобится, чтобы прочитать несложную диаграмку? А сколько десятков минут, чтобы ее нарисовать?
вопрос, сколько у тебя потребуется времени, чтобы прочитать предложение на японском, а сколько, чтобы написать?В отношении олбсуждаемой темы, сколько секунд тебе понадобится, чтобы прочитать несложную диаграмку? А сколько десятков минут, чтобы ее нарисовать?
Любой человек может посмотреть дизайн, который нарисовал дизайнер. Но вот людей, которые могут нарисовать хороший дизайн мало.
Любой человек может посмотреть на интерфейс, который разработал дизайнер интерфейсов. Но вот разработать хороший интерфейс может далеко не каждый.
Аналогии ясны?
Любой человек может посмотреть на интерфейс, который разработал дизайнер интерфейсов. Но вот разработать хороший интерфейс может далеко не каждый.
Аналогии ясны?
> Т.к. ИМХО для лубого компового языка тебе достаточно иметь "словарь" синтаксиса, и ты можешь писать на этом языке...
Конечно, при условии, что есть еще и "Нтилект"
Допустим ты случайно посмотрел не на ту строчку словаря, и использовал синтаксис неправильно.
Как и когда ты поймешь, что допустил ошибку?
Или допустим: ты посмотрел первое правило, но забыл посмотреть 247 правило подпункт 4бис, который отменяет первое правило для твоего случая.
Опять же: когда и как ты поймешь, что допустил ошибку?
Конечно, при условии, что есть еще и "Нтилект"
Допустим ты случайно посмотрел не на ту строчку словаря, и использовал синтаксис неправильно.
Как и когда ты поймешь, что допустил ошибку?
Или допустим: ты посмотрел первое правило, но забыл посмотреть 247 правило подпункт 4бис, который отменяет первое правило для твоего случая.
Опять же: когда и как ты поймешь, что допустил ошибку?
нет...
что бы рисовать диаграммы - навыки дизайна (творчества) не нужны...
Нужно только уметь расставлять значки на картинке... и стрелочки...
что бы рисовать диаграммы - навыки дизайна (творчества) не нужны...
Нужно только уметь расставлять значки на картинке... и стрелочки...
Я тоже могу раставлять всякие закорючки в фотошопе. Вот только ничего хорошего из этого не выйдет.
о системе российского налогообложения и свода американских законов мы сейчас не говорим. Мы говорим о логически правильном упорядочении "слов".
А если ты неправильно посмотрел или не туде - это проблемы только твоей невнимательности.
ЗЫ еще: если считать время просмотра - время взгладя и осмысления и считать время рисования как время самого процесса выведения линий на бумаге - анологии не проходят... Больше подходит вариант равенства времени редставления в уме диаграмы (или ее логических цепей...)
А если ты неправильно посмотрел или не туде - это проблемы только твоей невнимательности.
ЗЫ еще: если считать время просмотра - время взгладя и осмысления и считать время рисования как время самого процесса выведения линий на бумаге - анологии не проходят... Больше подходит вариант равенства времени редставления в уме диаграмы (или ее логических цепей...)
И кстати, какое творчество необходимо для разработки интерфейса?
Это тоже по сути всякие квадратики, стрелочки, кружочки и т.д.
Это тоже по сути всякие квадратики, стрелочки, кружочки и т.д.
т.е. на язык написания диаграмм в принципе можно забить ?Лёха! Объясни - зачем ты всё время пытаешься уговорить себя и других, что изучать что-то новое не нужно? Сначала мне пытался доказать, что ООП ботать не нужно, т.к. всё, что можно сделать с его помощью, можно сделать и без его помощи. Теперь пытаешься убедиться, что UML изучать не надо. Что дальше? Отрицание необходимости XML и XSLT?
ну это уж точно не нужно
ежик, разговор не о нужности или ненужности, а о возможности прочитать и воспроизвести...
Я признаю, что если придумали какой-то стандарт чего-то, то что бы идти вперед - его стоит знать...
Но я не признаю его жизненной необходимости.... Как например - UML
Я признаю, что если придумали какой-то стандарт чего-то, то что бы идти вперед - его стоит знать...
Но я не признаю его жизненной необходимости.... Как например - UML
никто не говорит о жизненной необходимости, речь о полезности
Отрицание необходимости XML и XSLT?ТЫ говоришь.
> А если ты неправильно посмотрел или не туде - это проблемы только твоей невнимательности.
Дык, за внимательность - приходится платить: временем, повышенной усталостью и т.д.
ps
Да, и не совсем понятно, почему ты считаешь, что синтаксик UML проще, чем синтаксик какого-нибудь перла, или естественного языка.
Дык, за внимательность - приходится платить: временем, повышенной усталостью и т.д.
ps
Да, и не совсем понятно, почему ты считаешь, что синтаксик UML проще, чем синтаксик какого-нибудь перла, или естественного языка.
Перл не так уж и прост в синтаксисе, между прочим.
Да, почему ты уверен, что на UML у тебя не будут получаться, например, такие перлы?:
ps
т.е. как ты поймешь, что написать можно проще?
int ParseInt(string s)
{
switch (s)
{
case "0":
return 0;
case "1":
return 1;
...
case "99":
return 99;
case "100":
return 100;
}
return 0; //ну не смогла я
}
ps
т.е. как ты поймешь, что написать можно проще?
значит я не до конца понял суть концепции UML, ибо очень слабо представляю себе, каким образом к диаграме относится вышеприведенный фрагмент кода?
Но вот людей, которые могут нарисовать хороший дизайн мало.Причем знание УМЛ этими людьми на качесто дизайна влияет слабо. Более того, при необходимости УМЛ учится за пару недель.
Конечно, раскручен он сильно, тут сложно спорить. Отобьешь себе дополнительную строчку в резюме
какая разница, за сколько времени он учится? хоть за час. Если он реально улучшает программинг, то это хороший навык, даже если его можно легко выучить. Или тебе кажется хорошей методикой только та, что должна изучаться годами?
Как знание какого-либо языка может улучшить программинг?
по-моему, я наверху привел конкретный пример из личного опыта
Аффтару треда: UML еще никому не помог грамотнее спроектировать. Никому и никогда. Единственная его заслуга -- это то, что картинки к документации будут понимать другие лучше и без лишних слов. Основной принцип такой:
Например, я когда-то делал веб-проект, нарисовал схему: страницы, формы, основные ссылки. По ходу дела забил на стандарты и стал просто рисовать "как умею". Всем понравилось, зачот поставели!
Но ни в коем случае не стоит UML делать самоцелью, как говорят корпоративные русские, "внедрить технологию".
| В UNL-диаграмме надо рисовать не все подряд очевидные вещи, а то, что неочевидно, нетривиально и нестандартно. Другими словами, в UML-диаграмме должны быть тонкости реализации. |
Например, я когда-то делал веб-проект, нарисовал схему: страницы, формы, основные ссылки. По ходу дела забил на стандарты и стал просто рисовать "как умею". Всем понравилось, зачот поставели!
Но ни в коем случае не стоит UML делать самоцелью, как говорят корпоративные русские, "внедрить технологию".
примера не заметил, повтори для тупых
еще раз - как применение УМЛ позволяет улучшить дизайнерские навыки? вот я лично кружочки и квадратики с детства умею рисовать
еще раз - как применение УМЛ позволяет улучшить дизайнерские навыки? вот я лично кружочки и квадратики с детства умею рисовать
тред просто порезали:
и... чем новое приложение стало лучше старого?
тем, что превратилось в продавабельный продукт
а с точки зрения разработчика - оно стало в несколько раз (по исходным кодам) меньше, быстрее, гораздо легче подвержимо тестированию и внесению новых функциональностей
а с точки зрения разработчика - оно стало в несколько раз (по исходным кодам) меньше, быстрее, гораздо легче подвержимо тестированию и внесению новых функциональностей
Мне просто сомнительна сама валидность перехода диаграмма - код. Хотя Люксофт считает, что да.
Technology Snake Oil, Part 1: UML
I was told by someone recently at ThoughtWorks that I was so old that I "added to the company's diversity". Well, I've decided to take this sage old-timers wisdom and put it to some good use. In the development world, we keep getting sold Snake Oil in one guise or another, and I'm going to start pointing out some snake oil. Starting with the most venerated of crappy technology: UML.
Some of us craggy old-timers remember the time before UML, when we had Booch, Rumbaugh, and several other competing diagramming notations. The Holy Grail was going to be the Unified Modeling Language, which would solve all our problems and finally give us software developers a universal language, for everything from use cases through structure to deployment. And that's what we got. A classic example of "be careful what you ask for". UML feels like a compromise between a group of people, and it's so general that it's almost useless. The standards bodies keep bolting on new stuff to try to get it to the point of basic usefulness, but it just makes it worse. Does anyone really use Object Constraint Language to decorate their diagrams so that they can generate code that Just Works? I have never seen a case where you couldn't get it done faster by writing the code, then reverse engineering it into one of the expensive tools. Of course, it's good to design things before you code them, but a white board is much better. Combine the nature of UML with the fact that you can't ever show its diagrams to business analysts or end users because it is too obtuse, and I end up doing most of my architecture and design work in Visio (and I'm no fan of it either). It creates diagrams you can show everyone that capture the essence of what you are doing just before you implement it.
I'm not just a tourist in the UML and RUP world -- the company I worked for in the dim and distant past used RUP, and we foisted Heavy Duty Object-oriented Analysis and Design on clients, and used it ourselves. Why do you think I'm so militantly agile now? It just flat doesn't work for 90% of the types of projects that real developers write. And it's Bastard Child Model Driven Architecture is featured in an upcoming Snake Oil entry...
(c) Neal Ford, ThoughtWorks
Technology Snake Oil, Part 1: UML
I was told by someone recently at ThoughtWorks that I was so old that I "added to the company's diversity". Well, I've decided to take this sage old-timers wisdom and put it to some good use. In the development world, we keep getting sold Snake Oil in one guise or another, and I'm going to start pointing out some snake oil. Starting with the most venerated of crappy technology: UML.
Some of us craggy old-timers remember the time before UML, when we had Booch, Rumbaugh, and several other competing diagramming notations. The Holy Grail was going to be the Unified Modeling Language, which would solve all our problems and finally give us software developers a universal language, for everything from use cases through structure to deployment. And that's what we got. A classic example of "be careful what you ask for". UML feels like a compromise between a group of people, and it's so general that it's almost useless. The standards bodies keep bolting on new stuff to try to get it to the point of basic usefulness, but it just makes it worse. Does anyone really use Object Constraint Language to decorate their diagrams so that they can generate code that Just Works? I have never seen a case where you couldn't get it done faster by writing the code, then reverse engineering it into one of the expensive tools. Of course, it's good to design things before you code them, but a white board is much better. Combine the nature of UML with the fact that you can't ever show its diagrams to business analysts or end users because it is too obtuse, and I end up doing most of my architecture and design work in Visio (and I'm no fan of it either). It creates diagrams you can show everyone that capture the essence of what you are doing just before you implement it.
I'm not just a tourist in the UML and RUP world -- the company I worked for in the dim and distant past used RUP, and we foisted Heavy Duty Object-oriented Analysis and Design on clients, and used it ourselves. Why do you think I'm so militantly agile now? It just flat doesn't work for 90% of the types of projects that real developers write. And it's Bastard Child Model Driven Architecture is featured in an upcoming Snake Oil entry...
(c) Neal Ford, ThoughtWorks
Что я вынес из изучения UML. Язык не искуственный. Появился с развитием технологии объектно ориентированного анализа и проектирования различных систем. В концепцию языка заложенено описание модели системы( для системы тоже есть определение ) с точки зрения объектно ориентированного подхода. Модель системы рассматривается как множество объектов взаимодествующих друг с другом. Так как система есть реальность, а модель есть её приближённое представление, то для того чтобы чтобы достигнуть необходимого е, где е=реальность-модель, нужно представить в модели все необходимые структурные и динамические свойства системы. UML как раз их описывает. Сам язык органично вписывается в концепцию RUP (Rational Unified Process ) - итерационной разработки програмных комплексов и вдобавок на некоторых case- средствах(например Rational Rose) позволяет автоматизировать некоторые шаги разработки. Например в розе элемент любой диаграммы это не просто рисунок в правой части рабочей области, а еще некоторый объект со своим идентификатором описаный в файле модели. К нему есть доступ через API для VBA. Можно писать скрипты для создания по диаграмме некоторого рабочего кода. Я работал над одним проектом, так там модель данных для оракловой базы была описана через диаграмму классов. Был скрипт на VB который по этой диаграмме создавал схему для БД. Проектируя очередной модуль, проектировщик не задумывался над описанием DDL схемы. Вобщем для сложных систем UML -это решение. Если модель простая, думаю подымать все диаграммы просто не нужно.
Оставить комментарий
stm7884696
хм...вот в соседнем треде прочитал, что UML - это круто...
А что это - не знаю...
Может кто скинет ссылочку на вводный курс на русском ?