Структура и поведение в UML

Question

У меня были некоторые вопросы относительно структуры и поведения модели, использующей UML, и взаимосвязи между ними:

1. Нашли ли вы какие-либо ограничения для UML в отношении спецификации или понимания взаимосвязи между структурой и поведением?
2. Мне было интересно, есть ли у вас практические идеи о том, как можно оптимизировать отношения между структурой и поведением, используя UML.
3. Знаете ли вы какие-либо инструменты UML, которые помогают лучше понять эти отношения или представить их гораздо проще?

Спасибо

Answer 1

1. Да:

   • Диаграмма последовательности читается на высоком уровне, показывая, как транзакция включает несколько компонентов; но это не очень хорошо (не читается) на детальном уровне, показывая, как транзакция включает в себя десятки методов (метод A вызывает метод B, который получает данные из методов D и E, а затем вызывает метод F и т. д.).

   • Глядя на диаграмму классов, вы можете увидеть базовый класс с несколькими подклассами; это почти ничего не говорит о поведении классов (это говорит лишь о том, что у них может быть общее поведение или, по крайней мере, общий API, а также какое-то отдельное поведение, уникальное для каждого подкласса).

2. Это большой вопрос. Быстрый ответ: «Прикрепите текстовые заметки к объектам: диаграмм недостаточно без описательного текста».

3. Нет, я не совсем; инструмент UML поможет вам создать диаграммы UML (и сгенерировать код из диаграмм), но как вы его используете, решать только вам. Был замечательный продукт, описанный в книге под названием Объектно-ориентированное моделирование в реальном времени (1994), который был исполняемой моделью, то есть сама модель имела поведение, но я не знаю ни одного инструмента UML, подобного этому. Самое близкое, что мне известно, - это возможность "кругового обхода" между моделью и кодом (т.е. генерировать код из модели и модель из кода).

Answer 2

Я думаю, что все изменилось в отношении полезности UML для melculetz.

1. В Visual Studio 2010 я могу определить отношения ассоциации, которые будут генерировать составные классы. Я могу указать кратность и классификаторы классов. Я также могу генерировать классы из модели.
   В настоящее время я пытаюсь визуально смоделировать фазы системы, чтобы визуально определить методы для объекта конечного автомата. Это моя попытка объединить структуру и поведение. Проверьте мой блог, чтобы увидеть, как я вхожу. Class Analyzer визуально выражает поведение объектов класса. Ограничение снято.

2. Я думаю, что ответ заключается в том, чтобы обратить ваши методы разработки в сторону MDA. Вы создадите больше классов, но выгода в плане управляемости и повторного использования (там, где вы формируете свои усилия).

3. Я все еще работаю над своей моделью, но я считаю, что VS2010 обещает хорошие инструменты для управления процессом разработки. Я еще не исследовал моделирование пользовательского интерфейса, но слышал слухи. Возможно, все неправильно, но я думаю, что, работая с Lightswitch, я также смогу смоделировать пользовательский интерфейс.

Answer 3

Звучит как домашнее задание. Wiki может рассказать вам все о UML.

Ограничения UML такие же, как и любая форма общения. Чем проще ваш язык, тем меньше вы можете общаться, и тем понятнее будет ваше общение. Форма, подобная квадрату или кругу, обозначает структуру, линия обозначает связь, стрелка указывает движение или поток. Вы можете улучшить это, определив значение других свойств, таких как направление, жирность, цвет, количество чисел, различные формы. Вы можете включить мультимедийные слои, такие как аудио или видео, движение, всплывающие подсказки, но теперь мы больше не говорим об UML.

Мои любимые инструменты UML - доска и некоторые маркеры сухого стирания.

Answer 4

UML позволяет вам указать сигнатуру метода и сгруппировать методы в классы, но он вообще ничего не говорит о том, какой код вы используете в качестве реализации. Если это то, что вы подразумеваете под «поведением», я не думаю, что UML решает это вообще на уровне класса.

Еще хуже на уровне пользовательского интерфейса. У меня сложилось впечатление, что UML совершенно не подходит для определения пользовательских интерфейсов.

Я думаю, что усилия, необходимые для встраивания всего в UML, больше или равны кодированию приложения, с дополнительным бременем инструментов UML, заключающимся в плохих IDE и невозможности доказать правильность UML так, как вы можете с помощью модульного тестирования.

UML сильно перепродан, ИМО. Я считаю это удобным обозначением для неформального общения между разработчиками, не более того. Он никогда не был и не будет объектно-ориентированным эквивалентом технических чертежей.