Я правильно представляю внедрение зависимостей в UML?

Question

Итак, я пытаюсь начать работу с диаграммами классов UML, и в качестве своего рода упражнения я пытаюсь смоделировать некоторый существующий код. Допустим, у меня есть это:

public interface IDataContextWrapper : IDisposable
{
     //blah blah blah
}

public class DataContextWrapper<T> : IDataContextWrapper where T : DataContext, new()
{
     //blah blah blah
}

public class ArtistRepository
{
     L2SDCWrapper.Interfaces.IDataContextWrapper dataContext;

     public ArtistRepository()
         : this(new DataContextWrapper<ChinookDataContext>())
     {
     }

     public ArtistRepository(IDataContextWrapper dc)
     {
         dataContext = dc;
     }

     //blah blah blah
}

Я придумал это:

Мои опасения:

• Как правильно спроектировать внедрение конструктора (я думаю, это то, что вы бы назвали) в классе ArtistRepository? Я чувствую, что моя диаграмма не точно отражает ее.
• Как правильно составить схему объявления класса DataContextWrapper?

Answer 1

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

Тем не менее, вот пара указателей:

1. Зависимости довольно слабые, неспецифичные связи. Два Интерфейсы должны быть связаны обобщением (наследованием).
2. UML допускает представление обобщенных / шаблонных / параметризованных классов. Особенности моделирования таких классов зависят от используемого вами инструмента.
3. Конструктор ArtistRepository без параметров фактически создает объект анонимного класса. Вы можете представить этот класс в диаграмме классов, если хотите, но если вы действительно хотите получить этот уровень детализации, вероятно, лучше нарисовать диаграмму последовательности для конструктора.

Вот диаграмма классов вдоль этих линий, нарисованная в Sparx Systems 'Enterprise Architect:

Обратите внимание на параметризованный DataContextWrapper и абстрактный DataContext. Он не был включен в пример кода, но я предположил, что это абстрактный класс; если это фактически интерфейс, то отношения должны быть реализацией, а не обобщением.

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

Я только нарисовал зависимости для DataContextWrapper и ChinookDataContext от одного из них, но это только потому, что этот пример не слишком перегружен; Какое бы представление вы ни выбрали, оно, конечно, должно иметь оба отношения.

Я не смоделировал анонимный класс, созданный конструктором ArtistRepository. Для обзора я думаю, что это достаточно.