1) Majority of the software professionals in India don't know about UML (as much as 90%).
Это типично и для наших специалистов. Но означает ли это, что это проблема? Возникают новые программные языки и новые технологии программирования, которые в начале не знают более 99% профессионалов. Так узнают, если поймут полезность. Дело в том пока, что полезность UML неощутима пока, несмотря на огромное количество литературы. Возможно причина в том, что большинство команд делают небольшие короткоживущие проекты и справляются со своими проблемами без всякого UML?
2)For the professionals who know about UML... They really don't know why and in which phase should UML be used? In my programs almost 99% of the people believe that UML is used in the design phase and is used for designing systems. Professionals are greatly confused between analysis and design.
Несовсем понял, чем уж так смущенны или запутаны эти самые профессионалы? Анализ и конструирование - две стороны одной медали.
3)Managers consider Analysis and UML modeling as a waste of time. Their reasoning is "If one can create systems by writing code then why draw diagrams".
Это и понятно, если диаграммы используются лишь как картинки. Хотя, если я как программист рисую блок-схемы, разрабатывая алгоритм, и сохраняю это где-то, чем будет недоволен менеджер??
4)Young software professionals are more open and excited to using UML and doing it the right way, but the top management isn't technically sound enough to understand the importance of analysis and UML and hence they don't promote the usage of the same.
так пусть и доказывают этому самому топменеджменту, что решение задач с помощью UML происходит быстрее. Если уж они так возбуждаются от использования UML...
5)Unfortunately the most of the people in the top management are excellent man managers (not technical managers ) only bothered about parameters like,increasing the number of billable heads and the timeline there by increasing the revenues for the company while cutting the cost as much as possible.
ну и что? кесарю кесарево
6)Although UML is a set of standardized graphical diagrams for modeling the structural and behavioral complexities of any software system, A myth that UML is only meant for Object Oriented Programming Languages limits its usage.
Почему миф? UML изначально и создавался как визуальный ОО язык моделирования, однако он вполне может использоваться и для других языков программирования. Я бы уж сказал, что многие части UML как раз зачастую уводят нас от ОО проектирования...
7)Knowing the syntax of UML diagrams is a much simpler task as compared to knowing the best practices of using these diagrams to understand the structural and behavioral complexity of systems. For example knowing a syntax of a class diagram is a simple task while knowing and using the best practices of structural modeling using class diagrams is a completely different ball game.
Ну извините, знание родного языка не делает нас великолепным писателем или поэтом. К тому же и языку слава богу учат 16 лет - сначала в школе, потом в вузах. И что - что мы видим, посмотрите на этом же форуме, некоторые двух слов связать не могут, не то, что выразить свою мысль.
Так что естественно кроме синтаксиса, нужно учить семантику и прагматику, друзья - индийцы.
8)Even UML Diagrams need to be designed for parameters like usability, extensibility and flexibility.
Пардон, коллега. Давайте не класть все яйца в одну корзину. Для usability - есть совершенно другие и хорошо зарекомендовавшие себя методы, хроме того в ней еще много психологии и т.п. творчества.
extensibility - это что имеется в виду, расширяемость самого UML или передача семантики расширяемости с помощью UML? Если первое - так это благо, все же ясно - бери стереотип и вперед или в этом сложность? Ну извините, сколько там диалектов у английского?
9)As UML Diagrams represents the structural and behavioral complexity of a real world system (mostly business systems). By the very nature business systems are dynamic and will continuously change which will result in changes in the UML Models as well. Unfortunately I have seen people drawing UML diagrams in such a unplanned manner that with every change, their entire diagrams needs to be drawn. Ask yourself, In a highly compressed project life cycle do we have the time to re draw the diagrams again and again? This is one of the reasons why the UML diagrams and the code goes out of sync with the passage of time.
Ну и? Да меняется и что? Меняете же вы программный код, когда меняются требования? Что Вы делаете? так вы как раз и изменяете модель, ведь программный код - и есть модель, выраженная на языке программирования. В чем разница. Разница в наглядности. Тогда учите своих профессионалов читать код так - словно роман на ночь, чтобы при прочтении у человека в голове сразу весь функционал высвечивался - тогда UML и им подобные системы не нужны, согласен...
10)The time taken to draw these diagrams is also critical as well. I have seen software professional take more than a days time to draw one UML diagram while for an experienced professional, it might be a matter of minutes. Ask your self if the engineers start taking more than a day to draw a single diagram then how long will the analysis phase take and how will the project manager accommodate the same within the project life cycle.
Это уже дело технологий. Да первый раз сделать это сложно, и второй и возможно третий. Все это понятно. Программа - идеальная спецификация самой себя, но как говорится смотри выше. К тому же совсем не обязательно наверняка все поддерживать в идеально согласованном виде. Тут так же как и в программирования постепенно будет формироваться системный общеупотребительный уровень и некий прикладной авторский. Удачные решения будут переходить в разряд рекомендуемых или обязательных.
Знаете чем отличаются программисты 60-80 годов прошлого столетия от нынешних вундеркиндов. Нашим дедам приходилось продумывать свою программу до мелочей заранее, исправляй потом ошибку на перфоленте или перфокарте и жди очереди. Потому они делали гораздо меньше ошибок и тщательно продумывали свои решения. Сейчас проще программировать методом проб и ошибок, а порой и вообще сваливать "отладку" на тестировщиков и аналитиков, принимающих исполнение задачи.
Что-то говорит мне, дело в другом. Да не знают, но почему не хотят узнать?
Исследование по использованию UML в организациях