Hello everyone,

i was struggeling a lot in the past few days because i want to create an editor.

The requirements are the following:

• the editor should be maintainable in the future
• high performance
• plugins can be installed easily
• architecture: MVC

So, to achieve all this points i wanted to create the application from scratch instead of start coding like crazy until the first problems come up.

In order to this, my first step is to create a class diagram.

But this is exactly my problem. I don't know where to start (,though i know exactly what i want and how the application should act like)

Shall i start off with the view-classes or maybe with a specific one from the model-part...

So my question(s):

How do you start such diagrams (where is your starting point)? Do you follow a strict procedure or something else?

Thank you in advance.

I always start with a deck of index cards, as i find it's much quicker to try new ideas, and i'm less prone to wasting time making it pretty as i would with a dedicated uml program(starUML is my personal favorite btw). I got the idea about using CRC cards, from an article I cannot recall, but this covers it pretty well.

I start usually with classes i know will exist(usually model classes), and and a scratch pad of paper. I use the paper to prototype the interactions of classes, which i can then turn into real code down the line. As the design evolves, I start to get an idea of new classes that may be neccessary to facilite these interactions. I can write specific properties of classes on the back side when i know they will be needed. With a basic rough plan, I'll check and see if there are opportunities to use composition or inheritence to save work when it comes to coding. I model these relationships on a cork board with safety pins and string. If i like how it comes together I'll take a picture, and can use that as a reference for later. Once I've got a paper prototype down, I'll move it all into starUML, and export as a c++ project, which basically does all the boilerplate for you, and then I can go back to my scratch pad scrawlings to start writing implementations.

Thank you for your replies.

Hum, before starting drawing class diagram, you should have an idea of the different subsystems of the editor. (the editor, and e.g. to support plugin, there will be a plugin manager ), what constitute those subsystems and how they collaborates.

Then you might find out how to implement those subsystem and infer a class hierarchy, thus allowing you to get your diagram.

I always start with a deck of index cards, as i find it's much quicker to try new ideas, and i'm less prone to wasting time making it pretty as i would with a dedicated uml program(starUML is my personal favorite btw). I got the idea about using CRC cards, from an article I cannot recall, but this covers it pretty well.

I start usually with classes i know will exist(usually model classes), and and a scratch pad of paper. I use the paper to prototype the interactions of classes, which i can then turn into real code down the line. As the design evolves, I start to get an idea of new classes that may be neccessary to facilite these interactions. I can write specific properties of classes on the back side when i know they will be needed. With a basic rough plan, I'll check and see if there are opportunities to use composition or inheritence to save work when it comes to coding. I model these relationships on a cork board with safety pins and string. If i like how it comes together I'll take a picture, and can use that as a reference for later. Once I've got a paper prototype down, I'll move it all into starUML, and export as a c++ project, which basically does all the boilerplate for you, and then I can go back to my scratch pad scrawlings to start writing implementations.

A basic axiom states: "Function precedes Structure".

So i would first start to list all functionality that is required, once you have most of the functionality you can start to see how all of that fits into a structure.

One other piece of advice that i want to mention here is that I would definitely layer (3 Tiers) your functionality; Data Access Logic, Business Logic, Presentation Logic. It is so easy to make your application a mess when you don't separate the Presentation logic out of your Business logic.