Диаграммы классов UML концептуальные vs спецификация vs реализация
в настоящее время я читаю UML Мартина Фаулера дистиллированный. Я только что осветил раздел о диаграммах классов, где он делает сильный акцент на необходимости сортировать перспективы перед моделированием диаграмм классов. Однако я немного смущен тем, как это выглядит практически при рисовании диаграмм классов. Я понимаю, что теоретические выводы меняют значение ассоциации с одной точки зрения на другую, например.
Я думаю, мой главный вопрос было бы так, если бы, например, я моделировал простую систему упорядочения, как он делает в книге, диаграммы классов выглядели бы иначе и содержали бы разные количества обозначений с одной точки зрения на другую. Например, с концептуальной точки зрения я бы просто показал классы и некоторые неопределенные ассоциации и их множественность, а затем при моделировании с точки зрения спецификации включал бы навигацию и основные операции и поля класса.
Я был бы очень признателен некоторые рекомендации по этому вопросу, поскольку я действительно хотел бы лучше понять эту тему.
4 ответов
хороший вопрос. Вот некоторые мысли из моего собственного опыта, не могу сказать, что Мартин согласится (!) но, тем не менее, надеюсь, полезно.
вкратце: основное отличие заключается в формальности и выборе дизайна для отношений.
Я нашел следующее полезным:
базовая структура: грубо отображает UML Фаулера как эскиз и выполняется на доске в интерактивном режиме. Основная цель-понять общую структуру. Очень неформальный. В частности, фокус на отношениях - это просто их идентификация, а не формализация - поэтому нет мощности, поведения удаления, выбора классов контейнеров и т. д.
Модель Предметной Области. Точная модель, ориентированная на формализацию отношений. В частности, именование ассоциации заканчивается, определяя мощность и подтверждая поведение удаления. Не учитывает судоходность или выбор классов контейнеров для мощности >1. Один из лучших методов, которые я знаю для изучения предметная область.
Я почти всегда буду использовать оба вышеперечисленных. Ключевая вещь из модели домена-использовать именование на основе глаголов, а не на основе ролей, потому что она описывает, почему существует связь (эффективно обрабатывает бизнес - правила: например, "заказ должен быть размещен точно одним клиентом"). Я использую шаблон именования, описанный в Simsion & Witt'ы.
необходимо выполнить работу по переводу модели домена в рабочий код, особенно в отношениях. Языки программирования не очень хорошо поддерживают отношения, поэтому ассоциации должны быть переведены в атрибуты участвующих классов. Именно в этот момент в игру вступает навигационная способность, а также выбор типа коллекции для кратности >1. Здесь также должны быть указаны все операции. Лично я не нахожу этот тип диаграмм особенно полезным. Модель домена плюс код дают мне все, что я необходимость.
Я буду использовать "UML как язык программирования", только если я использую исполняемый инструмент UML.
извинения если это немного бессвязно, надеюсь, это поможет...
PS: Если вы хотите лучший пример именования на основе глаголов, у меня есть пост в моем блоге. Пожалуйста, не воспринимайте это как саморекламу, просто нет смысла повторять здесь.
вот как я объясняю идеи разработчикам.
концептуальные отношения. Это уровень, на котором должно произойти соединение. Вы не должны видеть соединение от концептуального к реализации - это сигнал плохого дизайна.
спецификация определяет алгоритм без определения реализации. На диаграмме классов это может быть представлено как абстрактный класс. Алан Шаллоуэй называет методы, которые попадают в эту область "Сержантские методы": они просто выкрикивают приказы.
реализация - это то, где происходит фактическая работа. Это может быть представлено конкретными классами, которые реализуют ваши абстрактные спецификации.
точно, диаграммы классов UML - это просто обозначения, которые вы можете (и должны) по-разному в зависимости от фазы разработки программного обеспечения. Вы можете начать только с классов, атрибутов и ассоциаций, затем уточнить диаграмму, чтобы добавить информацию о типах для атрибутов, затем навигация, методы классов, квалификаторы для ассоциаций ... пока вы не получите полную диаграмму классов, готовую к фазе реализации
обратите внимание, что вы можете даже повторить до точки, в которой вы удалите ассоциации и замените их атрибутами сложных типов, чтобы иметь диаграмму классов, еще более похожую на конечную реализацию. Это зависит от вас, как использовать диаграммы классов на каждом этапе.
книги Мартина Фаулера-дерьмо для меня (e.g мое личное чувство), как только он начинает говорить о диаграмме классов!! Я согласен с другими диаграммами, но диаграмма классов должна быть более прагматичной, а не просто высокого уровня!!
это всегда одна и та же теория, которую вам нужно моделировать на более высоком уровне абстракции, а затем моделировать то, что вам действительно нужно. Я предпочитаю быстро предоставить работающий код и показать его клиенту. С первого этапа мы начинаем моделирование для того, чтобы иметь функциональные требования, но и код. Как только мы закончим этот второй этап, мы снова покажем его клиенту и снова предоставим диаграммы классов UML для изменения того, что нужно сделать. После 10 итераций мой проект обычно заканчивается. Например мой проект длится от 3 до 6 месяцев. Это очень сложный проект и мои клиенты обычно довольны. Используя рекомендацию Мартина Фаулера, мой проект не был бы завершен в течение 12-18 месяцев, и клиент, безусловно, будет разочарованный.