Действительно ли UML является языком программирования?
Мог UML использоваться для программирования компьютерной системы самостоятельно без языка реализации поддержки, например, схематически изображает прямо к машинному коду (возможно, через C или C++ и т.д.), без человеческого вмешательства кодирования.
12 ответов
Я собираюсь пойти против общей тенденции и поделиться опытом, который показывает, что UML может делать сегодня, и какой может быть будущая версия UML (или другой подход к моделированию).
Сначала немного истории.
Давным-давно, когда люди программировали компьютеры на сборке (здесь не вернулись). Затем появились языки более высокого уровня, такие как C и Basic. Программисты, которые очень хорошо разбирались в ассемблере, утверждали, что вы не можете полностью выразить все, что процессор способен делать (оптимизированным образом), на языке более высокого уровня. На самом деле они были правы. Некоторые вещи были гораздо менее оптимальными с точки зрения памяти и производительности на языках более высокого уровня, потому что вы не могли полностью контролировать инструкции, отправляемые процессору.
Дело в том, что языки более высокого уровня предоставляли гораздо более абстрактную форму выражения. Итак, они уловили, и через некоторое время людям было все равно, что вы не можете полностью контролировать все аспекты процессора, потому что разработчики были намного более продуктивными ( Закон Мура также помог).
Подобные раунды произошли с объектно-ориентированными языками, и снова с управляемыми языками. Каждый раз становился доступным более высокий уровень абстракции, который в конечном итоге выигрывал, потому что его было более эффективно использовать в качестве разработчика. Фактически, как правило, неэффективность более высоких уровней выражения исчезает по мере того, как компиляторы становятся лучше, а методы оптимизации улучшаются.
Развитие, управляемое моделями, - это более высокий уровень выражения. Вы не можете полностью представить любой код, который вы могли бы написать, скажем, на C # или Java. Особенно не из коробки.Однако можно создать очень значительную часть приложения непосредственно из модели UML.
Я руководил созданием кода на основе UML для нескольких довольно крупных проектов. Во многих случаях мы могли бы сгенерировать от 30% до 60% всего исходного кода (реальных, корпоративных) приложений. И это только с небольшой командой, пишущей генераторы для определенной области. В конце концов, целая индустрия будет создавать инструменты для создания все большего и большего количества реальных приложений из моделей.
Это следующий шаг в естественной эволюции, которую мы наблюдаем в нашей отрасли снова и снова, с тех пор, как первые ассемблерные коды абстрагировали коды операций (вероятно, что-то было до этого, но это было до меня).
Есть несколько инструментов для преобразования диаграмм моделирования UML в код, в частности, диаграммы состояний UML. Например, еще в 2000 году я использовал инструмент под названием «Rhapsody» (от I-Logix), который преобразовывал диаграмму UML в C ++. Это было круто, потому что инструмент мог запускать конечный автомат напрямую, а также мог запускать код на удаленном компьютере (в данном случае на плате с vxworks).
Но, вообще говоря, UML лучше всего использовать в качестве инструмента моделирования. Используйте его для моделирования вашей системы и создания диаграмм для ваших проектных документов или чего-то еще. Затем используйте эти знания для организованной разработки вашей системы.
Диаграмма классов может быть преобразована в язык программирования в зависимости от используемого инструмента UML. Думаю, вам все еще нужно кодировать собственную бизнес-логику и т. Д.
Да, это возможно, просто проверьте подходы, такие как ExecutableUML (и новый стандарт в том же духе), которые полагаются на использование языка действий для выражения деталей поведения системы (своего рода псевдокод с итераторами, условиями и действиями создания, чтения, обновления и уничтожения).
Это стоит совсем другого обсуждения. Моделирование системы с достаточной точностью и детализацией для создания 100% кода не всегда окупается. Я предпочитаю придерживаться своего принципа Парето (или правила 80-20) для разработки на основе моделей: 20% усилий по моделированию достаточно для генерации 80% кода приложения
Более подробное объяснение здесь: http://modeling-languages.com/blog/content/pareto-principle-applied-mdd
Краткий ответ: нет. Некоторые инструменты моделирования UML могут генерировать Java, C ++ и код на других языках программирования. Однако то, что он генерирует, обычно - это интерфейсы и отношения классов. Эти инструменты создают заглушки, реализация которых еще не завершена, поэтому необходимо вмешательство человека.
UML может моделировать конечный автомат. Таким образом, он может представлять машину Тьюринга. Достаточно сложный компилятор может прочитать это представление и создать двоичное (исполняемое) представление машины Тьюринга .
Итак, мой ответ - да.
Править
Поскольку мой ответ кажется некоторым неприятным ... позвольте мне пояснить, что этот "компилятор с достаточной сложностью" полностью вымышлен и, вероятно, далек от будущего ... но, судя по другим ответам, есть некоторые программы, которые могут генерировать некоторый шаблонный код или даже генерировать и запускать целую программу.
Я думаю, это доказывает, что UML (или его часть) может считаться языком программирования, но, вероятно, не лучшим.
Это не так. Нисколько.
Он не может принимать решения (если) или запускать циклы. Это не столько язык программирования, сколько конечный автомат. По крайней мере, конечный автомат может принимать решения. UML даже не имеет состояния.
Краткий ответ: в настоящее время вы не можете сгенерировать 100% кода.
Вы, вероятно, могли бы сгенерировать структуру классов своих систем с помощью диаграммы классов и, возможно, часть тела методов с помощью диаграмм взаимодействия и / или диаграмм состояний, но я думаю, что об этом.
Теоретически? Да, вы можете использовать гаджиллион диаграмм конечных автоматов и описать все с кропотливой детализацией, затем соединить диаграммы конечных автоматов с методами в диаграмме классов и запустить какой-нибудь ужасно сложный инструмент для генерации всего этого.
Но это не то, что вам нужно. Вы не получите больше свободы в том, как вы выражаете себя, потому что вам нужно использовать правильный синтаксис, чтобы инструмент понимал все, что вы пишете. Более того, вы сможете написать фактический код самостоятельно за гораздо меньшее время, чем вам потребовалось бы для создания всех этих диаграмм - и единственное, что это дает вам, это то, что код является точной копией спецификации. (потому что спецификация генерирует код). Это может быть хорошо, но поскольку у вас нет реального кода, это также означает, что отладка означает отладку диаграмм, а это почти наверняка будет практически невозможно.
Некоторые ссылки для WeNeedAnswers , так как я был , поэтому затронул его комментарий:
- Домашняя страница UML группы управления объектами
- Архитектура на основе моделей
- Sparx Enterprise Architect продукт, который поддерживает MDA
- Sparx '« Инструмент MDA для архитектуры, управляемой моделями «
- » Корпоративный архитектор с архитектурой, управляемой моделями » технический документ
Это должно быть начало.
Семантика действий UML поддерживает выделение/удаление объектов, чтение/запись атрибутов и локальных переменных, вызов операции, бросание и поимку исключений, навигацию по отношениям, блоки, циклы и условное поведение, и многое другое.
См.:
http://abstratt.com/blog/2008/11/02/what-can-uml-do-for-you/
http://abstratt.com/blog/2008/11/07/executable-models-with-textuml-toolkit-12-m1/
Тем, кто говорит "нет": вопрос касается UML, а не "инструментов UML, которые вы используете", друзья. UML - это огромный язык, а инструменты реализуют его подмножество, которое часто может быть довольно маленьким.
Теперь существует полностью стандартизированная OMG, полная по Тьюрингу семантика выполнения для подмножества UML 2.3, известная как «Базовый UML» (fUML). См. здесь для ознакомления с эталонной реализацией и указателем на спецификацию OMG. Также продолжается работа над стандартным языком действий UML OMG.
Хорошо это или плохо, когда эта работа будет завершена, fUML станет языком программирования.
- Эд