Кто-нибудь использовал UML с OCL? Используют ли это программисты или только аналитики, которые не пишут код?

Question

Я пытаюсь обдумать, почему мы сначала подходим к проблеме проектирования и выбираем визуальный метод (UML), вместо того, чтобы начинать с формальных спецификаций, которые также являются исполняемыми (прототипирование RAD), мы начинаем с диаграммэто не может быть легко доказано, чтобы работать.Поэтому, когда приходит время доказать свойства модели, мы обнаруживаем, что нам необходимо определить ограничения в нашем проекте, поэтому мы разрабатываем формальный синтаксис (OCL) для определения ограничений модели.Я с трудом понимаю этот скачок назад к тому, с чего мы начали.Я считаю, что проекты UML, обремененные OCL (даже примеры, показанные в брошюрах), нечитаемы, даже более непроницаемы, чем множество символов и соглашений UML.Итак, что я хочу знать: какие ключевые области используются OCL в современном мире разработки программного обеспечения, и для кого это уместно или стоит изучить?Как выглядит ваша работа?Используют ли архитекторы, которые никогда не пишут код, UML и OCL, или программисты, которые также проектируют и проектируют системы с той же командой, которая его реализует?

[updated: Во-вторых, мне кажется, что AgileРазработка кажется своего рода противоположностью «тяжеловесным» процедурам, и что специфичный для предметной области язык для ограничений проектных диаграмм, таких как OCL, не кажется очень гибким.Используется ли UML + OCL в ЛЮБЫХ «Agile» магазинах, или Scrummers всегда его избегает?]

Answer 1

Интересный вопрос.

«Святым Граалем» языка объектных ограничений было создание структуры, которая в сочетании с UML позволяла инструменту преобразовывать его в конкретный объектный граф / метамодель, то есть набор классов, которые уже имели свою базовую структуру и ограничения. так что все, что нужно было сделать разработчику, это реализовать бизнес-методы. (все это не зависит от языка)

JBuilder из Borland попытался изменить это в своей корпоративной версии, и Delphi с ECO также практично использовала OCL (хотя и не в качестве входного преобразования), поддерживая возможности Query. Фактически, Андерс Инвер из Borland / BoldSoft, и один из сотрудников ОЭС, написал форвард по Библии OCL, Object Constraint Language, второе издание (addison wesley)

Мое личное мнение таково, что недостаточно, чтобы оправдать обучение. Без использования специализированных (и дорогих) инструментов модель UML / OCL по-прежнему сложно проверить в реальных условиях, и получаемая вами ценность является незначительной (если вообще что-то) по сравнению с разработкой, основанной на итеративных тестах. Ситуация с независимостью от языка переоценивается, давайте посмотрим правде в глаза, как только мы запустим Java, C #, Delphi, C ++ или любой другой путь, в аду мы не сможем сгенерировать что-то еще, это просто не практично.

Что бы это ни стоило, мне еще предстоит увидеть Model Driven Development с OCL, реально используемым в реальном мире для реального проекта. (кроме как для проверки концепции) В последнее время в реальном мире, похоже, работают гибкие процессы, Scrum и т. д., и просто интерактивная разработка с использованием стандартных сред IDE со стандартными языками и пользовательскими историями (возможно, с некоторым UML на доске или раскадровке).

Answer 2

Преимущество определения ограничений OCL в ваших моделях заключается в возможности указать все бизнес-правила вашего домена, которые вы не можете представить с помощью графических конструкций UML (например, кратности - это ограничения, которые могут быть графически представлены как часть определение ассоциации, говорящее о том, что атрибут A класса C должен быть больше 5, также является ограничением, но в этом случае оно должно быть определено в OCL, поскольку UML не предоставляет для этого графический синтаксис)

Очевидно, что это было бы очень полезно, если бы инструменты генерации кода могли принимать эти ограничения и автоматически генерировать код, который их применяет (например, как условия if в методах Java или как триггеры в базах данных, которые вызывают исключение, когда данные нарушают правило).

К сожалению, не так много инструментов, предлагающих эту функцию (см. Список здесь: http://modeling -languages.com / content / list-ocl-tools ), но ситуация постепенно улучшается

Answer 3

Многое изменилось.

UML 2.5 использовал Eclipse OCL для исправления многочисленных ошибок во встроенном OCL UML 2.0 ... 2.4.

SysML использует инструменты Papyrus и Eclipse OCLSysML next.

Eclipse OCL предоставляет гораздо более мощный пользовательский интерфейс и генератор кода OCL2Java, так что OCL, встроенный в Ecore / UML, обеспечивает гораздо более приемлемый / исполняемый код.1009 *

OCL, встроенный в UML, никогда серьезно не выполнялся.

Определение OCL самого OCL плачевно.

Answer 4

Я работал с OCL Constraints как небольшая часть моей дипломной работы бакалавра. У Borland (теперь Microfocus) был интересный подход, благодаря которому Java-код создавался из ограничений OCL. Вы определили, что переменная X должна быть> = 0 или не пуста, и вместе создали команды assert для автоматической проверки.