Структура и поведение в UML
У меня были некоторые вопросы относительно структуры и поведения модели, использования UML и взаимосвязи между ними:
- Нашли ли вы какие-либо ограничения для UML в отношении спецификации или понимания взаимосвязи между структурой и поведением?
- Мне было интересно, есть ли у вас практические идеи о том, как можно оптимизировать отношения между структурой и поведением, используя UML.
- Знаете ли вы какие-либо инструменты UML, которые помогают лучше понять эти отношения или представить их гораздо проще?
Спасибо
4 ответа
Да:
Диаграмма последовательности читается на высоком уровне, показывая, как транзакция включает в себя несколько компонентов; но это не очень хорошо (не читается) на детальном уровне, показывая, как транзакция включает в себя десятки методов (метод A вызывает метод B, который получает данные из методов D и E, а затем вызывает метод F и т. д.).
Глядя на диаграмму классов, вы можете увидеть базовый класс с несколькими подклассами; это почти ничего не говорит вам о поведении классов (это говорит лишь о том, что у них может быть общее поведение или, по крайней мере, общий API, плюс некоторое индивидуальное поведение, уникальное для каждого подкласса).
Это большой вопрос. Быстрый ответ: "Прикрепите текстовые заметки к объектам: диаграмм недостаточно без описательного текста".
Нет, я не совсем; инструмент UML поможет вам создать диаграммы UML (и сгенерировать код из диаграмм), но как вы его используете, решать вам. В книге под названием "Объектно-ориентированное моделирование в реальном времени" (1994) был описан замечательный продукт, который представлял собой исполняемую модель, то есть сама модель имела поведение, но я не знаю ни одного инструмента UML, подобного этому. Самое близкое, что я знаю, - это возможность "кругового обхода" между моделью и кодом (т.е. генерировать код из модели и модель из кода).
Звучит как домашнее задание. Вики может рассказать вам все о UML.
Ограничения UML такие же, как и любая форма общения. Чем проще ваш язык, тем меньше вы можете общаться, и тем понятнее будет ваше общение. Форма, подобная квадрату или кругу, обозначает структуру, линия обозначает отношение, стрелка обозначает движение или поток. Вы можете улучшить это, определив значение других свойств, таких как направление, жирность, цвет, количество чисел, различные формы. Вы можете включить мультимедийные слои, такие как аудио или видео, движение, всплывающие подсказки - но теперь мы больше не говорим об UML.
Мои любимые инструменты UML - доска и некоторые маркеры сухого стирания.
Я думаю, что все изменилось в отношении полезности UML для melculetz.
В Visual Studio 2010 я могу определить отношения ассоциации, которые будут генерировать составные классы. Я могу указать кратность и классификаторы классов. Я также могу генерировать классы из модели.
В настоящее время я пытаюсь визуально смоделировать фазы системы, чтобы визуально определить методы для объекта конечного автомата. Это моя попытка интегрировать структуру и поведение. Проверьте мой блог, чтобы увидеть, как я вхожу. Class Analyzer визуально выражает поведение объектов класса. Ограничение снято.Я думаю, что ответ заключается в том, чтобы обратить ваши методы разработки в сторону MDA. Вы будете генерировать больше классов, но выгода в плане управляемости и повторного использования (где вы формируете свои усилия).
Я все еще работаю над своей моделью, но я считаю, что VS2010 обещает хорошие инструменты для управления процессом разработки. Я еще не исследовал моделирование пользовательского интерфейса, но слышал слухи. Возможно, все неправильно, но я думаю, что, работая с Lightswitch, я также смогу смоделировать пользовательский интерфейс.
UML позволяет вам указывать сигнатуру метода и группировать методы в классы, но ничего не говорит о том, какой код вы используете в качестве реализации. Если это то, что вы подразумеваете под "поведением", я не думаю, что UML обращается к нему вообще на уровне класса.
Еще хуже на уровне пользовательского интерфейса. У меня сложилось впечатление, что UML совершенно не подходит для определения пользовательских интерфейсов.
Я думаю, что усилия, необходимые для встраивания всего в UML, больше или равны кодированию приложения, с дополнительным бременем инструментов UML, заключающимся в плохих IDE и невозможности доказать правильность UML так, как вы можете с помощью модульного тестирования.
UML перепродан, IMO. Я считаю это удобным обозначением для неформального общения между разработчиками, не более того. Он никогда не был и не будет объектно-ориентированным эквивалентом технических чертежей.