Jump to content

  • Log In with Google      Sign In   
  • Create Account

Class Diagram - where to start?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 //Lumia   Members   -  Reputation: 503

Like
0Likes
Like

Posted 22 February 2013 - 08:25 AM

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) wacko.png

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.

 

 



Sponsor:

#2 Sporniket   Members   -  Reputation: 344

Like
1Likes
Like

Posted 22 February 2013 - 08:45 AM

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.


Space Zig-Zag, a casual game of skill for Android by Sporniket-Studio.com


#3 Burnt_Fyr   Members   -  Reputation: 1240

Like
2Likes
Like

Posted 22 February 2013 - 09:52 AM

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.



#4 //Lumia   Members   -  Reputation: 503

Like
0Likes
Like

Posted 22 February 2013 - 11:17 AM

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.

So this is what i've already done.
The actual problem is more about how to arrange these information and put it all together in the diagram. Sometimes the amount of information is just too high and if you want to set all the dependencies visible in the diagram, you have to work on several classes at the same time. But this can get counter-productive simply because you are working a bit here and a bit there.
So i was looking for something more abstract, something that has a strict procedure (kind of guideline).

 

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.

 

This is something that sounds great to me because it breaks down the complexity.
I'll give it a try and keep you up to date on how it evolves.
 

 



#5 JurgenK   Members   -  Reputation: 106

Like
1Likes
Like

Posted 23 February 2013 - 07:08 AM

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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS