Формы, проверки или соединения в UML? [Дубликат]

Question

Формы, проверки или соединения в UML? [Дубликат]

Вы используете объект, содержащий ссылку нулевого значения. Таким образом, он дает пустое исключение. В примере строковое значение равно null, и при проверке его длины произошло исключение.

Пример:

string value = null;
if (value.Length == 0) // <-- Causes exception
{
    Console.WriteLine(value); // <-- Never reached
}

Ошибка исключения:

Необработанное исключение:

System.NullReferenceException: ссылка на объект не установлена в экземпляр объекта. в Program.Main ()

6

uml diagram

задан Simon H 28 April 2011 в 06:30

4 ответа

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

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

3

ответ дан Cory Foy 27 August 2018 в 02:14

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

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

2

ответ дан Jordi Cabot 27 August 2018 в 02:14

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

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

0

ответ дан UML GURU 27 August 2018 в 02:14

Другие вопросы по тегам:

uml diagram

Похожие вопросы:

score 5 · Accepted Answer

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

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

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

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

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

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

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

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

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