Click here to Skip to main content
15,906,467 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
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.
Posted
Updated 9-Dec-12 13:56pm
v2
Comments
Sergey Alexandrovich Kryukov 9-Dec-12 11:52am    
Actually, there will be many problems of OOP design in this project. As to the one you are trying to describe, it's not just clear. What does it mean: "limited depending on each type"? How and why would you like to have them "unlimited"? Also, you need to tag the platform and the language. Please use "Improve question" above.
--SA
Daskul 9-Dec-12 20:04pm    
I apologize, Thank you for your response. By saying limited I mean, for example not all members of an UMLEntity can be static, private like members of an UMLInterface. and you cant use all those modifiers at the same time.

I hope this answers your question
Sergey Alexandrovich Kryukov 9-Dec-12 20:20pm    
So what? Do you want modifiers to change from base class to derived classes? This is impossible (unfortunately). But what's the idea? how could it help you to build the file system and the tools?
--SA
Daskul 9-Dec-12 20:32pm    
What I am trying to say is, should I create an interface like IAccessModifier which will have properties like (IsStatic, IsAbstract etc) and will be implemented by Entities and Members? because I think i cant achieve it by inheritance, can it be(?).

My idea is one Item on the diagram will be an instance of UMLEntity (UMLEntity or UMLInterface) then when the user wants to save it (want to come back to it the next day) the data will be stored in an XML, then it will be use to load and instatiate all the objects (UMLEntity) again and create the diagram.

I am using WPF.
Sergey Alexandrovich Kryukov 9-Dec-12 21:06pm    
For persistence, better use Data Contract. This way, persistence will be totally separated from semantic (agnostic). Data Contract is based on Reflection and can work with any members you include, even private.
--SA

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
 
Share this answer
 
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
 
Share this answer
 
v2
Comments
Daskul 12-Dec-12 20:16pm    
reviewing your previous comments sir, i guess youre right that its better or should i say the right thing, to just build my own simple data contract. i can still use parsing then using relfection right?
Sergey Alexandrovich Kryukov 12-Dec-12 20:20pm    
Yes you can and I think you should. Reflection is a valuable feature available only on new platforms, it would be a sin to ignore it.
Did you see my new post with class hierarchy? Will you accept it, too?
--SA
Daskul 12-Dec-12 20:23pm    
thanks a lot. as a beginner i find it overwhelming :)
but ill just review it till i get the concept of the hierarchy.
Sergey Alexandrovich Kryukov 12-Dec-12 20:27pm    
Well, this is natural. I would expect you could find it insufficient at the same time. :-)
If you are a beginner, it's may be a time to begin. :-) The problem is not simple at all, for a beginner. Anyway, your further questions are welcome, no matter if you accept the answer(s) or not.
--SA
Daskul 12-Dec-12 20:45pm    
ALL answers, comments, questions are VERY much accepted :-)
can you some reference about OOP, Interface Programming and other important concepts of software engineering? cant find ebooks on some of those.
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:
C#
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:
C#
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:
C#
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:
C#
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:
C#
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)3-architecture expressed in the form of (meta)2 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
 
Share this answer
 
Comments
Daskul 14-Dec-12 1:12am    
Sir can i ask how to implement or more detailed approach on the Type class? how can i use it? what should be the content of the class? who extends it? who and how will i interact with the object?

as well as the relationship. cant quite figure out how to implement it. can you make it crystal clear for me sir?

thanks a lot
Sergey Alexandrovich Kryukov 14-Dec-12 13:32pm    
There is almost nothing in this class. I can see only the Namespace, at the moment. It should not have any public functionality. It's major role is to be the abstract base for its descendants. Who extends is? -- see the rest of the classes.

I forgot to write a disclaimer to my sketch: use it on your own risk. :-)
—SA

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900