UML Диаграммы классов Концептуальные против Спецификации против Реализации

Question

Я сейчас читаю UML Distilled Мартина Фаулера.Я только что рассмотрел раздел, посвященный диаграммам классов, в котором он делает сильный акцент на необходимости разобраться с перспективой, прежде чем моделировать диаграммы классов.Тем не менее, я немного озадачен тем, как это выглядит практически при рисовании диаграмм классов.Я понимаю, что теоретические последствия меняют значение ассоциации, например, с одной точки зрения на другую.

Думаю, мой главный вопрос заключается в том, что если бы, например, я моделировал простую систему заказов, как он это делает вкнига, будут ли диаграммы классов выглядеть по-разному и содержать различное количество обозначений от одной перспективы к другой.Например, с концептуальной точки зрения я бы просто показал классы и некоторые смутные ассоциации и их множественность, а затем при моделировании с точки зрения спецификации включал бы навигационные возможности и базовые операции и поля классов.

Я был бы очень признателен за некоторые рекомендации поэто как я действительно хотел бы иметь лучшее понимание этой темы.

Answer 1

Хороший вопрос. Вот некоторые мысли из моего собственного опыта; не могу сказать, согласится ли Мартин (!), но, тем не менее, полезно.

В итоге: основное отличие заключается в формальности и выборе дизайна для отношений.

Я нашел следующее полезное:

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

• Модель предметной области. Точная модель, ориентированная на формализацию отношений. В частности, именование ассоциации заканчивается, определяя количество элементов и подтверждая поведение удаления. Не учитывает судоходность или выбор контейнерных классов для количества элементов> 1. Один из лучших методов, которые я знаю для изучения проблемной области.

Я почти всегда буду использовать оба вышеперечисленных. Ключевым моментом в модели предметной области является использование именования на основе глаголов, а не ролей - потому что оно описывает, почему существуют отношения (фактически раскрывает бизнес-правила: например, «заказ должен быть размещен ровно одним клиентом»). Я использую шаблон именования, описанный в книге Simsion & Witt .

Необходимо выполнить работу по переводу модели предметной области в рабочий код, особенно в отношениях. Языки программирования не очень хорошо поддерживают отношения, поэтому ассоциации должны быть переведены в атрибуты участвующих классов. В этот момент вступает в игру навигация, а также выбор типа коллекции для кратности> 1. Здесь также должны быть указаны все операции. Лично я не считаю этот тип диаграмм особенно полезным. Модель предметной области плюс код дают мне все, что мне нужно.

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

Извинения, если это немного бессвязно, надеюсь, это поможет ...

PS: Если вам нужен лучший пример именования на основе глаголов, у меня есть запись в моем блоге . Пожалуйста, не принимайте это как саморекламу, просто нет смысла повторять здесь.

Answer 2

Вот как я объясняю идеи разработчикам.

• Концептуальными являются отношения. Это уровень, на котором должно происходить соединение. Вы не должны видеть связь между концептуальным и реализационным - это сигнал плохого дизайна.

• Спецификация определяет алгоритм без определения реализации. На диаграмме классов это может быть представлено как абстрактный класс. Алан Шаллоей называет методы, которые попадают в эту сферу, «методами сержанта»: они просто лают приказы.

• Реализация - это то, где происходит настоящая работа. Это может быть представлено конкретными классами, которые реализуют ваши абстрактные спецификации.

Answer 3

Точно, диаграммы классов UML - это просто обозначение, которое вы можете (и должны) по-разному в зависимости от фазы разработки программного обеспечения, в которой вы находитесь. Можно начать только с классов, атрибутов и ассоциаций, а затем уточнить диаграмму, добавив информацию о типах атрибуты, затем навигация, методы класса, квалификаторы для ассоциаций ... пока вы не получите полную диаграмму классов, готовую к этапу реализации

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

Answer 4

Книги Мартина Фаулера - чушь для меня (например, мои личные чувства), как только он начинает говорить о диаграмме классов !! Я согласен с другими диаграммами, но диаграмма классов должна быть более прагматичной, а не только дизайн высокого уровня !!

Это всегда та же теория, что вам нужно моделировать на более высоком уровне абстракции, а затем моделировать то, что вам действительно нужно. Я предпочитаю быстро предоставить работающий код и показать его клиенту. С этого первого этапа мы начинаем моделирование, чтобы иметь функциональные требования, а также код. Когда мы закончим этот второй этап, мы снова покажем его клиенту и снова предоставим диаграммы классов UML, чтобы изменить то, что нужно сделать. После 10 итераций мой проект обычно заканчивается. Например, мой проект длился от 3 до 6 месяцев. Это действительно сложный проект, и мои клиенты обычно довольны. По рекомендации Мартина Фаулера мой проект не был бы завершен через 12-18 месяцев, и заказчик, безусловно, был бы разочарован.