macOS tools for software design

[MrFusion]

Hello everyone

I am curious as to which software you use to design your application, before you start coding it in xCode. My current approach is to start with one class and add others as the program grows (bottom up), but maybe it is better to do "top down"? That is first design the classes and their interactions before coding them in xCode. Google points towards "UML" to do this, but I haven't found a good program so far.
What are your favourite (open source) programs for this task?

Thanks

 

[ethical]

I was under the impression is was all done in Xcode? Designing classes, linking classes etc etc. But then again I'm still learning Obj-C so don't really know alot.

 

[JoshDC]

If you just want to get a feel for the structure of your program I'd use a pencil and paper. When designing many parts of a program (algorithms, classes, UI), it's often a good idea to take a step away from the computer. UML is a much more formal way of representing a program and sometimes that level of formality isn't required.

 

[trule]

I think you can do UML in Dia (mac version) and its fairly good. You can also do ER diagrams which are really useful for database design.

 

[chown33]

A) Pen and paper (take photos with digital camera, for a digital record).
B) Notes written in plain text files (plain text is easier to share).
C) Entity-relationship models (e.g. Xcode models) as appropriate.
D) Skeleton classes.

ER models can help understand and clarify classes and relationships, even if you never use them in the code.

Skeleton classes only define methods and types, but have no internals and usually no ivars. Skeletons should compile without errors, but don't actually do anything.

The rationale for skeleton classes is to see what interfaces are actually needed, and what they really need to look like. The reason for not filling in any methods is to stay at the higher level of interfaces and relationships, not the lower level of specific algorithms and implementations.

At any point, you can start filling in some high-level method bodies, writing them solely in terms of the lower-level interfaces, or in terms of internal methods. Do this in order to find out if the lower-level skeleton classes are providing an adequate interface. However, you must be willing to throw every line of this code away, should you discover something new and significant: it's research, not development. If you're not willing to throw it all away, then at least be honest and call it the first implementation. You will probably still throw it away, because you should always plan to throw the first one away.

Don't rely on tools to provide clarity. UML can be bungled or over-complicated, as can anything else.

 

[MrFusion]

A) Pen and paper (take photos with digital camera, for a digital record).
B) Notes written in plain text files (plain text is easier to share).
C) Entity-relationship models (e.g. Xcode models) as appropriate.
D) Skeleton classes.

ER models can help understand and clarify classes and relationships, even if you never use them in the code.

Skeleton classes only define methods and types, but have no internals and usually no ivars. Skeletons should compile without errors, but don't actually do anything.

The rationale for skeleton classes is to see what interfaces are actually needed, and what they really need to look like. The reason for not filling in any methods is to stay at the higher level of interfaces and relationships, not the lower level of specific algorithms and implementations.

At any point, you can start filling in some high-level method bodies, writing them solely in terms of the lower-level interfaces, or in terms of internal methods. Do this in order to find out if the lower-level skeleton classes are providing an adequate interface. However, you must be willing to throw every line of this code away, should you discover something new and significant: it's research, not development. If you're not willing to throw it all away, then at least be honest and call it the first implementation. You will probably still throw it away, because you should always plan to throw the first one away.

Don't rely on tools to provide clarity. UML can be bungled or over-complicated, as can anything else.

Thanks for the detailed reply. I will stay away from UML then. I start over all the time. I already used plain text to some extent, but D looks like a good idea.

 

[MrFusion]

If you just want to get a feel for the structure of your program I'd use a pencil and paper. When designing many parts of a program (algorithms, classes, UI), it's often a good idea to take a step away from the computer. UML is a much more formal way of representing a program and sometimes that level of formality isn't required.

Good old fashion pen and paper. Ok, I will stick with that.

 

[Cromulent]

Hello everyone

I am curious as to which software you use to design your application, before you start coding it in xCode.

Pen and paper. Simple, easy to learn and basically free.

Seriously though why does it need to be a software solution? Contrary to common sense I tend to solve the vast majority of my problems when I am away from the computer not when I am using it. That includes software design issues.

A decent time spent drawing diagrams and scribbling notes on random scraps of paper generally gives me a better idea of what I am doing.

Edit: Note to self: read thread before responding .