UML-инструмент
Инструмент UML — это программное приложение , которое поддерживает некоторые или все обозначения и семантику, связанные с унифицированным языком моделирования ( UML ), который является отраслевым стандартом моделирования общего назначения языка для разработки программного обеспечения .
Инструмент UML здесь широко используется для включения прикладных программ, которые не ориентированы исключительно на UML, но поддерживают некоторые функции унифицированного языка моделирования либо в качестве надстройки , либо в качестве компонента , либо как часть их общей функциональности.
Виды функциональности [ править ]
Инструменты UML поддерживают следующие виды функциональности:
Диаграмма [ править ]
Построение диаграмм в этом контексте означает создание и редактирование UML диаграмм ; это диаграммы, соответствующие графическим обозначениям унифицированного языка моделирования.
Использование UML-диаграмм как средства рисования диаграмм (в основном) объектно-ориентированного программного обеспечения обычно согласовывается с разработчиками программного обеспечения. Когда разработчики рисуют диаграммы объектно-ориентированного программного обеспечения, они обычно следуют нотации UML. С другой стороны, часто обсуждается, нужны ли эти диаграммы вообще, на каких этапах процесса разработки программного обеспечения их следует использовать и как (если вообще нужно) их следует поддерживать в актуальном состоянии. Примат программного кода часто приводит к тому, что диаграммы устаревают.
Проектирование туда и обратно [ править ]
Под циклическим инжинирингом понимается способность инструмента UML выполнять генерацию кода из моделей и генерацию модели из кода (так называемое обратное проектирование), сохраняя при этом и модель, и код семантически согласованными друг с другом. Генерация кода и реверс-инжиниринг более подробно описаны ниже.
Генерация кода [ править ]
Генерация кода в этом контексте означает, что пользователь создает диаграммы UML, которые имеют некоторые связанные данные модели, а инструмент UML извлекается из части или всего исходного кода диаграмм для программной системы. В некоторых инструментах пользователь может предоставить скелет исходного кода программы в виде шаблона исходного кода , где предопределенные токены затем заменяются частями исходного кода программы в процессе генерации кода.
Часто цитируемая критика заключается в том, что диаграммам UML не хватает деталей, необходимых для содержания той же информации, которая содержится в исходном коде программы: Джек В. Ривз утверждает, что окончательное воплощение проекта находится в исходном коде. (Его часто цитируемое заявление о том, что «Кодекс — это дизайн». [1] было неверно истолковано как означающее, что нет необходимости в артефактах проектирования программного обеспечения среднего и высокого уровня, таких как UML-диаграммы или документы с требованиями к программному обеспечению).
Реверс-инжиниринг [ править ]
Реверс-инжиниринг в этом контексте означает, что инструмент UML считывает исходный код программы в качестве входных данных и извлекает из него данные модели и соответствующие графические диаграммы UML (в отличие от несколько более широкого значения, описанного в статье « Обратное проектирование »).
Некоторые из проблем реверс-инжиниринга:
- Исходный код часто содержит гораздо более подробную информацию, чем хотелось бы видеть в диаграммах проекта. Эта проблема решается путем реконструкции архитектуры программного обеспечения .
- Данные диаграммы обычно не содержатся в исходном коде программы, поэтому инструмент UML, по крайней мере на начальном этапе, должен создать случайное расположение графических символов нотации UML или использовать какой-либо алгоритм автоматического расположения для размещения символов в таким образом, чтобы пользователь мог понять диаграмму. Например, символы следует размещать на панели рисования в таких местах, чтобы они не перекрывались. Обычно пользователю такой функциональности инструмента UML приходится вручную редактировать автоматически сгенерированные диаграммы, чтобы придать им некоторую значимость. Также часто не имеет смысла рисовать диаграммы всего исходного кода программы, поскольку они представляют слишком много деталей, чтобы представлять интерес на уровне диаграмм UML.
- существуют особенности языка В некоторых языках программирования , такие как шаблоны классов или функций языка программирования C++ , которые, как известно, трудно автоматически преобразовать в диаграммы UML во всей их сложности.
Обмен моделями и диаграммами [ править ]
XML Metadata Interchange (XMI) — это формат обмена моделями UML. XMI не поддерживает UML Diagram Interchange , что позволяет импортировать UML-диаграммы из одной модели в другую.
Трансформация модели [ править ]
Ключевой концепцией, связанной с инициативой архитектуры, управляемой моделями, является возможность преобразования одной модели в другую. Например, может потребоваться преобразовать модель предметной области, независимую от платформы, в модель, специфичную для платформы Java, для реализации. Также возможно провести рефакторинг моделей UML для создания более кратких и правильно сформированных моделей UML. Можно генерировать модели UML из других нотаций моделирования, таких как BPMN , которая сама по себе является профилем UML . Стандарт, поддерживающий это, называется QVT для запросов/представлений/преобразований. Одним из примеров QVT- решения с открытым исходным кодом является язык ATL , созданный INRIA .
См. также [ править ]
- Список инструментов унифицированного языка моделирования
- Список инструментов разработки требований
- Метамоделирование
- Модельно-ориентированное проектирование
- КВТ
- Язык спецификации и описания (SDL)
Ссылки [ править ]
Внешние ссылки [ править ]
