Design Architecture of UML Editor

Please see my comments on persistence. If should be either Data Contract or something like that. It should be agnostic to UML. As soon as your persistence start depending on UML definitions or anything of application field, consider all your development dead. And it should be no XAML, because this way you lock yourself in dealing with geometry first. You need model first approach.

As to diagramming, please also see my past anwers:
Connect different controls[^],
Vector graphics software like CorelDraw or Inkscape in C# or VB.NET[^].

[EDIT]

Daskul wrote:

The study will be accepted only if I will traverse data back and forth from XML and Memory manually.

Let me comment on this.

I cannot believe you understand what's required of you properly. I think the matter of this is that you just need to do XML-related development by yourself, at the level of XmlWriter/XmlReader or something like that. Can you see the difference? Essentially, I don't think anyone wants you to produce that total manual trash. This is natural: study projects are normally done to benefit you with the possibilities of sharpening many useful skills. Working with XML on this level is a very useful productive and educational activity which can help you to become a really capable engineer.

You need to do some right thing on good reasonable level. Nobody wants monkey job from you. The conclusion? You need to do your own, maybe highly simplified (more exactly, limited in functionality) Data Contract persistence. You own. You just need to learn Reflection, reading attributes, properties, instantiation of types, etc. Based on that, you define type-agnostic storage and loading — saving and restoring of some object graph.

You can skip on System.Reflection.Emit. It is needed only for performance reason and compromises the maintenance of the serializer. Without it, it just repeats Reflection operations over and over instead of dynamic generation of serialization code. This is not too bad. In near past, when Microsoft Data Contract was not yet available and when I did not yet had all my knowledge of CIL and emitting of CIL code, I did such work. Nothing terrible.

—SA

OK, I'll show some very rough sketch of UML hierarchy. Very preliminary, pseudo-code, and only for Class Diagram and top level. Perhaps you well see that you might under-estimate the task.

Let's start with abstract top level of hierarchy:

abstract class Element {
    // Name: string;
    // UniqueId;
    // ...
}
abstract class NormativeElement : Element { }
abstract class InformativeElement : Element { }
class Comment : InformativeElement {
    // Content: string;
}

Let's classify NormativeElements into three entities:

abstract class Type : NormativeElement {
    // Namespace
}
abstract class Relationship : NormativeElement {
    // Stereotype: Stereotype;
    // StartingEnd: RelationshipEnd;
    // FinishingEnd: RelationshipEnd;
}
class Stereotype : NormativeElement { }

Now, model the types and generic type. Pay attention: we shall not classify them into types and generic types, for some good reasons:

class SimpleType : Type { }
class EnumerationMember : Element { }
class EnumerationType : SimpleType {
    // EnumerationMembers: Collection of EnumerationMember
}
class ComplexType {
    // Operations: Collection of Operation;
    // IsInternal : Boolean;
    // AccessLevel: AccessLevel;
}

class Class {
    // in UML, there is no distiction between class and struct
    // we also won't introduce generic type as a separate entity: it will be modelled
    // as a class with some generic parameters
    //
    // GenericParameters: Collection of GenericParameters
    // Attributes: Collection of Attribute
}

class GenericParameter {
    // GenericParameterConstraints : Collection of ComplexType
}

class Interface : ComplexType { }

class Member : Element { }
class Operation : Member {
    // returnType: Type;
    // parameters: Collection of ParemeterDescriptor;
    // AccessLevel: AccessLevel;
}
class Attribute : Member {
    // Type: Type;
}

enum AccessLevel { IsPrivate, IsProtected, IsPublic, } // "internal" could be a separate member
enum ParameterPassingMethod { In, Out, InOut }

class ParemeterDescriptor {
    // Type: Type;
    // PassingMethod: ParameterPassingMethod;
    // IsConstant: Boolean;
    // AccessLevel: AccessLevel;
}

Now, adding the relationships:

class Cardinality {
    // Min: uint;
    // MaxLength: uint; // Max = Min + MaxLengh, to avoid Max < Min, etc.
    // IsUnconstrant: use MaxLength or not
}

class RelationshipEnd {
    // Cardinality: Cardinality;
}

abstract class DependencyBase : Relationship { }
class Dependency : DependencyBase { }
class Permission : DependencyBase { }
class Usage : DependencyBase { }

class Generalization : Relationship { }
class Realization : Relationship { }

class Composition : Relationship { }
class UniComposition : Relationship { }
class Aggregation : Relationship { }
class UniAggregation : Relationship { }

Finally, the top of object hierarhy:

class Model : Element {
    // Elements: Collection of Element;
    // Diagrams: Collection of Diagram;
}
abstract class Diagram : Element { }
class ClassDiagram : Diagram {
    // Elements: Collection of elements, diagram view
    // additional refernces to same elements as in Model
}

// you will need to elaborate all other types of diagrams:
class UseCaseDiagram : Diagram { /* ... */ }
class UseSequenceDiagram : Diagram { /* ... */ }
class CollaborationDiagram : Diagram { /* ... */ }
class StateChartDiagram : Diagram { /* ... */ }
class ActivityDiagram : Diagram { /* ... */ }
class DeploymentDiagram : Diagram { /* ... */ }
// did I forget anything? :-)

You will also need to develop separate geometry classes and bind them with model classes as loosely as possible. You can face the problem of parallel hierarchies which can potentially compromise maintenance. I devoted a part of my CodeProject article to this problem. Please see: Dynamic Method Dispatcher[^].

To understand this chapter, you will need to read the whole article, which can be useful by itself.

What else? Well, you should understand the sense of what you are doing and why. This is a meta-model, a (meta)³-architecture expressed in the form of (meta)² model. Generally, if the set of some classes present some model, then the modeling of the notion of the class itself and related notions is a meta-model of a class of different models, a meta-meta-model…

—SA