UML - это язык программирования?
Может ли UML использоваться для программирования компьютерной системы самостоятельно, без поддержки языка реализации, например, диаграмм прямо в машинный код (возможно, через C или C++ и т. Д.), Без вмешательства человека в кодирование.
12 ответов
Я собираюсь пойти против общей тенденции и поделиться опытом, который показывает, что UML может сделать сегодня, и какой может быть какая-то будущая версия UML (или другой подход к моделированию).
Сначала немного истории.
Давным-давно, когда люди программировали компьютеры в сборке (не вернувшись сюда ВСЕ). Затем появились языки более высокого уровня, такие как C и Basic. Программисты, которые были очень хороши в сборке, утверждали, что вы не можете полностью выразить все, на что способен процессор (оптимизированным способом) на языке более высокого уровня. На самом деле они были правы. Некоторые вещи были гораздо менее оптимальными с точки зрения памяти и производительности на языках более высокого уровня, потому что вы не могли полностью контролировать инструкции, выданные процессору.
Дело в том, что языки более высокого уровня предоставляют гораздо более абстрактную форму выражения. Таким образом, они завоевали популярность, и через некоторое время люди на самом деле не заботились о том, что вы не можете полностью контролировать каждый аспект процессора, потому что разработчики были намного более производительными ( закон Мура также помог).
Подобные обходы происходили с объектно-ориентированными языками и снова с управляемыми языками. Каждый раз более высокий уровень абстракции становился доступным и в конечном итоге побеждал, потому что его было эффективнее использовать в качестве разработчика. Фактически, как правило, неэффективность на более высоких уровнях выражения исчезает по мере улучшения компиляторов и совершенствования методов оптимизации.
Модель управляемая разработка - это более высокий уровень выражения. Вы не можете полностью представить любой код, который вы могли бы написать, скажем, на C# или Java. Особенно не из коробки. Тем не менее, можно генерировать очень существенную часть приложения непосредственно из модели UML.
Я руководил разработкой кода на основе UML для нескольких довольно крупных проектов. Во многих случаях мы могли бы генерировать от 30% до 60% всего исходного кода приложений (реальных, корпоративного класса). И это только с небольшой командой, пишущей генераторы для определенного домена. В конце концов, за инструментами будет стоять целая индустрия, чтобы генерировать все больше и больше реальных приложений из моделей.
Это следующий шаг в естественной эволюции, которую мы снова и снова наблюдаем в нашей отрасли, с тех пор, как первая сборка кодов абстрагировала коды операций (возможно, было что-то до этого, но это было до моего времени).
Краткий ответ: нет. Некоторые инструменты моделирования UML могут генерировать Java, C++ и код на других языках программирования. Однако обычно генерируются интерфейсы и классовые отношения. Эти инструменты генерируют заглушки, для которых все еще необходимо обеспечить реализацию, поэтому необходимо вмешательство человека.
Существует несколько инструментов для преобразования диаграмм моделирования UML в код, в частности диаграммы состояний UML. Например, в 2000 году я использовал инструмент под названием "Rhapsody" (от I-Logix), который конвертировал бы диаграмму UML в C++. Это было круто, потому что инструмент мог запускать конечный автомат напрямую, а также запускать код на удаленном компьютере (в данном случае, на плате, на которой запущен vxworks).
Но, вообще говоря, UML лучше всего использовать в качестве инструмента моделирования. Используйте его, чтобы смоделировать вашу систему и предоставить диаграммы для ваших проектных работ, или что-то еще. Затем используйте эти знания для развития вашей системы в организованном порядке.
Теоретически? Да, вы можете использовать диаграммы конечного автомата gajillion и указать все кропотливо, затем соединить диаграммы конечных автоматов с методами в диаграмме классов и запустить какой-то ужасно сложный инструмент для генерации всего этого.
Но это не то, что вы хотели бы сделать. Вы не получите больше свободы в том, как выражаете себя, потому что вы должны использовать правильный вид синтаксиса, чтобы инструмент понимал все, что вы пишете. Не только это, но вы сможете сами написать реальный код за гораздо меньшее время, чем потребовалось бы для создания всех этих диаграмм - и единственное, что он дает вам, - это то, что код является точной копией спецификации. (потому что спецификация генерирует код). Это может быть хорошо, но поскольку у вас нет реального кода, это также означает, что отладка означает отладку диаграмм - и это почти наверняка будет практически невозможно.
В настоящее время существует полностью стандартизованная OMG семантика выполнения по Тьюрингу для подмножества UML 2.3, известная как "Foundational UML" (fUML). Посмотрите здесь для справочной реализации и указатель на спецификацию OMG. Также продолжается работа над стандартным языком действий UML OMG.
К лучшему или худшему, когда эта работа будет выполнена, fUML станет языком программирования.
- Эд
Да, это возможно, просто проверьте подходы, такие как ExecutableUML (и появляется новый стандарт в том же духе), которые полагаются на использование языка действий для выражения деталей поведения системы (своего рода псевдокод с итераторами, условиями, и создавать, читать, обновлять и уничтожать действия).
Совершенно другое обсуждение - это того стоит. Моделирование системы с достаточной точностью и детализацией, позволяющей генерировать 100% кода, не всегда окупается. Я предпочитаю придерживаться своего принципа Парето (или правила 80-20) для разработки на основе моделей: 20% усилий по моделированию достаточно для генерации 80% кода приложения
Более подробное объяснение здесь: http://modeling-languages.com/blog/content/pareto-principle-applied-mdd
UML может моделировать конечный автомат. Таким образом, он может представлять собой машину Тьюринга. Компилятор с достаточной сложностью может прочитать это представление и создать двоичное (исполняемое) представление машины Тьюринга.
Итак, мой ответ - да.
редактировать
Поскольку мой ответ кажется некоторым неприятным... позвольте мне уточнить, что этот "компилятор с достаточной изощренностью" является полностью воображаемым и, вероятно, далеко в будущем... но, как видно из других ответов, есть некоторые программы, которые могут генерировать некоторый шаблонный код или даже генерировать и запускать целую программу.
Я думаю, это доказывает, что UML (или некоторая его часть) квалифицируется как язык программирования, но, вероятно, не очень хороший.
Диаграмма классов может быть переделана в язык программирования в зависимости от используемого вами инструмента UML. Я думаю, что вам все еще нужно кодировать свою собственную бизнес-логику и т. Д.
Краткий ответ: как сейчас, вы не можете сгенерировать 100% кода.
Вероятно, вы могли бы сгенерировать структуру классов ваших систем с помощью Диаграммы классов и, возможно, часть тела методов с помощью диаграмм взаимодействия и / или диаграмм состояний, но я думаю, что именно об этом.
Семантика действий 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 - это огромный язык, и инструменты реализуют его подмножество, которое часто может быть довольно маленьким.
Некоторые ссылки на WeNeedAnswers, так как я был так затронут его комментарием:
- Домашняя страница UML группы управления объектами
- Модельно-управляемая архитектура
- Продукт Sparx Enterprise Architect, который поддерживает MDA
- Sparx " Инструмент MDA для модельно-управляемой архитектуры"
- Технический документ "Архитектура предприятия с модельно-управляемой архитектурой"
Это должно быть началом.
Это не. Не за что.
Он не может принимать решения (если) или выполнять циклы. Это не столько язык программирования, сколько конечный автомат. По крайней мере, ФСМ может принимать решения. У UML нет даже государства.
UML2 - это просто данные для вашего генератора кода.
Генератор кода обобщает код, используя данные из модели (например, шаблоны C++ обобщают код, используя структуры C++ в качестве модели).
Работая таким образом, вы можете создать полное приложение для создания, замены, обновления, удаления (CRUD) и поиска для любой данной модели.
Этот код реализует перехватчики, обратные вызовы, наследование или аналогичные методы, которые позволяют расширить функциональность с помощью рукописного кода, не затрагивая сгенерированный код (который должен рассматриваться как промежуточный код).