programm design

[akmalnuernberg]

hi guys,

when you try to solve a task, how do you start? A task like creating a programm for a vendor machine. I mean a complete one. The different goods, the changes, and also giving out the items are to be considered. How would you start? I looked in wikipedia, and what I found was something I think more for bigger projects.

Maybe this is not much related to C++, if not could you give some simple methodologies how to design a programm of this big, a medium one i would say.

Answer from a pro would be much appreciated :)

thanks

[exception]

This problem is usually referred to as "software engineering". Some of the aspects can be learned from books, but most of them have to be gained by experience. My workflow usually is:
- requirement capture
- requirement analysis
- (if it's oo, which it usually is): Object Oriented Analysis
- depending on the problem: algorithm design, library studies etc. - look what parts of the work already was done by others.
- depending on the problem: make special diagrams (mostly defined by the UML 2.0), such as timing- or activity diagrams where needed
- Object Oriented Design
- Preliminary implementation, then go back to step 1.

It seems to become more and more important to get early prototypes (I often make these in Smalltalk as 'prove of concept' work)

Plan to write the software three times. You will have to anyways, so you can as well plan it from the beginning (sadly, this statement is not completely meant as a joke).

[akmalnuernberg]

so, i have to go into software engineering anyways, which i'm trying to avoid since there are too much to learn, aren't there?

I learned C and a little bit C++. Now after I learned a bit more of C++, I'm find object oriented programming is somewhat interesting. I think I would like to go further into this field, although i'm studying mechatronics. So I guess, I will learn software engineering too.

I found some models of the workflow how to complete a software. Which one would you suggest for a beginner like me? I think the spiral one is the simplest although takes some times, and it fits my working style. I don't like to plan much in the beginning.

thanks for the reply by the way, and sorry, I think this thread doesn't fit the Forums for C++

[z05DSL3A]

I find Use cases a good place to start
http://en.wikipedia.org/wiki/Use_case

Generally I try to follow an Agile Unified Process
http://en.wikipedia.org/wiki/Agile_Unified_Process


for the second time today (people will think I'm on commission or somthing), Code Complete: A Practical Handbook of Software Construction is a very good book.

Synopsis
Widely considered one of the best practical guides to programming, Steve McConnell s original CODE COMPLETE has been helping developers write better software for more than a decade. Now this classic book has been fully updated and revised with leading-edge practices and hundreds of new code samples illustrating the art and science of software construction. Capturing the body of knowledge available from research, academia, and everyday commercial practice, McConnell synthesizes the most effective techniques and must-know principles into clear, pragmatic guidance. No matter what your experience level, development environment, or project size, this book will inform and stimulate your thinking and help you build the highest quality code.Discover the timeless techniques and strategies that help you: Design for minimum complexity and maximum creativity Reap the benefits of collaborative development Apply defensive programming techniques to reduce and flush out errors Exploit opportunities to refactor or evolve code, and do it safely Use construction practices that are right-weight for your project Debug problems quickly and effectively Resolve critical construction issues early and correctly Build quality into the beginning, middle, and end of your project

[akmalnuernberg]

thanks Grey Wolf,

i will study it!

p/s: wolves nowadays know how to write codes :)

[Return 0]

You need to write a software spec. I agree with Grey Wolf, start with use cases and then write requirements for each of those use cases. It is extremely important to plan before developing any system and by developing the blueprints first, you can focus on just the design without trying to figure out what you need as you design. Furthermore, in the business world it prevents scope creep caused by the scatter brained end users by locking in a baseline requirements list :)

return 0;

[akmalnuernberg]

thanks Return 0 and Grey Wolf for the book recommendation. I realise the importance of safety aspects, but I guess I won't touch the topic for now. thanks again you guys.

[akmalnuernberg]

I read about use case already. Something to ask, in my example, the vendor machine, the actors would be the buyer and the machine, aren't they? or is the machine belonged to the system?
but since the programm is controlling the machine, the machine would be the secondary actor, isn't it?

[bnbertha]

For a vending machine, the actor is really only the person using the machine. The machine is part of the system. I suppose you could go for another actor for the person maintaining the machine and one for refilling the machine, they all have slightly different interfaces.