Блог

Итак, я пытаюсь начать работу с диаграммами классов 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?

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

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

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

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

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

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

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

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