UML编辑器的设计架构 [英] Design Architecture of UML Editor

问题描述

我正在尝试基于作为学校项目的图创建一个UML类图编辑器和类文件生成器（PHP但是支持其他语言），我在设计我的类以适应时遇到了困难项目。



例如，如果我要创建一个类UMLEntity（这些是可以添加图表的项目）基类，它将由UMLClass和UMLInterface扩展两者都有UMLMember（UMLProperty，UMLMethod）。问题是UMLEntity和UMLMember都有修饰符（public，protected，private，static，abstract，final等），但是根据每种类型有限（例如，接口只能有公共成员，不能是静态的，接口不能是静态的）。所以也许我应该自动将这些成员设置为公开，但是如何？



任何人都可以帮助我找出这个场景的更好方法。



请帮帮我。



谢谢。

解决方案

您需要查看数据合同。请参阅：

http://msdn.microsoft.com/en-us /library/ms733127.aspx [ ^ ]。



请看我过去的答案我在哪里解释一下：

我如何在表单应用程序中使用XML文件编写器和阅读器？ [ ^ ]，

创建属性文件...... [ ^ ]。

-SA

请参阅我对持久性的评论。如果应该是数据合同或类似的东西。它应该与UML无关。一旦您的持久性开始取决于UML定义或应用程序字段的任何内容，请考虑您的所有开发时间。它应该不是XAML，因为这样你就可以先锁定自己处理几何体。你需要模型第一种方法。



至于图表，请同时查看我的过去的答案：

连接不同的控件 [ ^ ]，

矢量图形软件，如CorelDraw或C＃或VB.NET中的Inkscape [ ^ ]。

Daskul写道：

研究将只有当我手动地从XML和内存来回遍历数据时才被接受。

让我对此发表评论。



我简直不敢相信你明白你需要什么。我认为这个问题是你只需要在 XmlWriter / XmlReader 之类的 c>或类似的东西自己进行XML相关的开发那。你能看到区别么？从本质上讲，我认为没有人希望你制作完整的手册垃圾。这是很自然的：学习项目通常是为了让你受益，有可能提高许多有用的技能。在这个级别上使用XML是一项非常有用的生产和教育活动，可以帮助您成为一名真正有能力的工程师。



你需要做好一些正确的事情。合理的水平。没有人想要你的猴子工作。结论？您需要自己做，可能是高度简化（更确切地说，功能有限）数据合同持久性。你拥有。您只需要学习反射，读取属性，属性，类型的实例化等。基于此，您可以定义与类型无关的存储和加载 - 保存和恢复某些对象图。



您可以跳过 System.Reflection.Emit 。仅出于性能原因需要它并且损害串行器的维护。没有它，它只是反复重复Reflection操作，而不是动态生成序列化代码。这不是太糟糕。在近期，当微软数据合同尚未可用时，当我还没有完全了解CIL并发出CIL代码时，我做了这样的工作。没什么可怕的。

-SA

好的，我会展示一些非常粗略的草图UML层次结构。非常初步的伪代码，仅适用于类图和顶级。也许你很清楚你可能会低估这项任务。



让我们从抽象的顶级层次结构开始：

< pre lang =c＃> abstract class 元素{
// 名称：字符串;
// UniqueId;
// ...
}
abstract class NormativeElement：Element {}
abstract class InformativeElement：Element {}
class 评论：InformativeElement {
// 内容：字符串;
}

让我们来吧将 NormativeElements 分为三个实体：

  abstract   class 类型：NormativeElement {
  //  命名空间 
} 
  abstract   class 关系：NormativeElement {
  //  刻板印象：刻板印象;  
  / /   StartingEnd：RelationshipEnd;  
  //   FinishingEnd：RelationshipEnd;  
} 
  class 刻板印象：NormativeElement {} 
 

现在，对类型和泛型类型进行建模。注意：出于某些原因，我们不会将它们分类为类型和泛型类型：

  class  SimpleType：Type {} 
  class  EnumerationMember：Element {} 
  class  EnumerationType： SimpleType {
  //   EnumerationMembers：EnumerationMember的集合 
} 
 类 ComplexType {
  //  操作：集合操作;  
  //   IsInternal：Boolean;  
 < span class =code-comment> //   AccessLevel：AccessLevel;  
} 
 
  class 类{
  //   in UML，类和结构之间没有干扰 
  //  我们也不会介绍泛型类型作为一个单独的实体：它将被建模 
  //  作为一个类通用参数 
  //    
  //   GenericParameters：GenericParameters的集合 
  //  < span class =code-comment>属性：属性集合 
} 
 
  class  GenericParameter {
  //   GenericParameterConstraints：ComplexType的集合 
} 
 
  class 接口：ComplexType {} 
 
 类成员：元素{} 
 类操作：成员{
  //   returnType：类型;  
  //  参数：ParemeterDescriptor的集合;  
  //   AccessLevel：AccessLevel;  
} 
  class 属性：成员{
  //  类型：类型;  
} 
 
 枚举 AccessLevel {IsPrivate， IsProtected，IsPublic，}  //  internal可以是一个单独的成员 
 枚举 ParameterPassingMethod {In，Out，InOut} 
 
  class  ParemeterDescriptor {
 < span class =cod电子评论> //  类型：类型;  
  //  < span class =code-comment> PassingMethod：ParameterPassingMethod;  
  //   IsConstant：Boolean ;  
  //   AccessLevel：AccessLevel;  
} 
 

现在，添加关系：

  class 基数{
  //   Min：uint;  
  //   MaxLength：uint; // Max = Min + MaxLengh，以避免Max< Min等。 
  //   IsUnconstrant：使用MaxLength  
} 
 
  class  RelationshipEnd {
  //  基数：基数;  
} 
 
  abstract   class  DependencyBase：Relationship {} 
  class  依赖：DependencyBase {} 
  class 权限：DependencyBase {} 
  class 用法：DependencyBase {} 
 
  class 泛化：关系{} 
  class 实现：关系{} 
 
  class 组成：关系{} 
  class  UniComposition：Relationship {} 
  class 聚合：关系{} 
  class  UniAggregation：关系{} 
 

最后，对象的顶部hierarhy：

  class 模型：元素{
  //  元素：元素集合;  
  //  图表：图表集合;  
} 
  abstract   class 图表：元素{} 
  class  ClassDiagram：图表{
  //  元素：元素集合，图表视图 
  //  对相同元素的附加引用在模型中 
} 
 
  //  你需要详细说明所有其他类型的图表： 
  class  UseCaseDiagram：图表{ / *  < span class =code-comment> ... * / } 
  class  UseSequenceDiagram：Diagram { / *   ... * / } 
  class  CollaborationDiagram：Diagram { / *   ... * / } 
  class  StateChartDiagram：图表{ / *   ... * / } 
  class  ActivityDiagram：图表{ / *   ... * / } 
  class  DeploymentDiagram：图{ / *   ... * / } 
  //  我忘记了什么吗？ ： - ） 
 

您还需要开发单独的几何类并将它们与模型类绑定为尽量松散。您可能会面临并行层次结构的问题，这可能会影响维护。我将CodeProject文章的一部分用于此问题。请参阅：动态方法调度程序 [ ^ ]。



要理解本章，您需要阅读整篇文章，它本身就很有用。



还有什么？那么，你应该理解你在做什么以及为什么这样做。这是一个元模型，（meta） ³ -architecture以（meta） ² 模型的形式表达。通常，如果某些类的集合呈现一些模型，那么类本身和相关概念的概念的建模是一类不同模型的元模型，元元模型......

-SA

I am trying to create a UML Class Diagram Editor and Generator of Class Files in (PHP but open to support for other language) based on the Diagram as a school project and I am having a difficulty on designing my classes to fit with the project.

for example, if I will create a class UMLEntity(these are the items that can be added diagram) base class which will be extended by UMLClass and UMLInterface that both have UMLMember (UMLProperty, UMLMethod). The problem is UMLEntity and UMLMember both have modifiers (public, protected, private, static, abstract, final etc) but limited depending on each type (ex. interface can only have public members and cannot be static, interface cannot be static). so maybe I should automatically set those members as public, but how?

Can anyone help me out what is the better way for this scenario.

Please help me out.

Thank you.

解决方案

You need to look at Data Contract. Please see:
http://msdn.microsoft.com/en-us/library/ms733127.aspx[^].

Please see my past answer where I explain it:
How can I utilize XML File streamwriter and reader in my form application?[^],
Creating property files...[^].

—SA

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

这篇关于UML编辑器的设计架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！