Using Charts and Diagrams before Programming?

I'm reading this book OOP Demystified. It seems pretty good. I'm getting a better understanding of OOP.

It says that OOP programmers use flow charts and pseudo code to describe processes. Do programmer still use flow charts? I've only see them used in books that don't use UML. This book does teach some basic UML however.

The book also talks about the use of ER diagrams. However, I've only used those with databases not with OOP. The book doesn't go into detail as to how one uses ERD to describe the relationship between objects in OOP.

I'm just trying to verify some things.

If these things are used, do you have any suggestions as to how i can expand my knowledge? I just want to stick to the basics and build. In the past, i thought one book or so would solve my problems only to bite off to much at a time and get nothing accomplished.

Thanks!

Quote:

---

It says that OOP programmers use flow charts and pseudo code to describe processes.

---

That's quite a generalisation. What's an 'OOP programmer', anyway? Surely even those who primarily code in an object-oriented fashion use other paradigms, at least some of the time? And, if they exist, surely they can't all use flow chats and pseudocode.

As for me, I scribble vague diagrams of my design on bits of scrap paper, then code something that contradicts it all.


Seriously: if you're in a team, do as everyone else does. This just makes life easier.
If you're own your own, you can do what you please.

Drawing diagrams when designing a system architecture does help a lot to communicate your design to others, and to visually see where your design could be improved.

UML, I find, is more help for specifications than designs. I never use it, but people do.
I had to look up ERD. It looks terribly verbose for a diagram form. Never seen it used in practice, but others here (with more 'real world experience', perhaps!) would probably have.


With any designs and specifications, though, it is best not to be too rigid. Describe what you need to; eliminate ambiguity; nothing more.

Thanks penagate!

I do know that if I'm working alone, i can do whatever i want. But what i want to do is learn so that I can demonstrate a diverse skill set. I think it would be more appealing to a future employer to show that I do some planning before i begin development. Further, i learned procedural programming first as with most people, i'm trying to plan ahead so i don't fall into the same trap.

I realize that most programmers probably don't do much of any planning but since I'm alone and don't have help, i feel I need to develop a good work ethic. Even some rudiment of a basic structure is better than just being plan sloppy.

Best wishes.

Style will evolve over time, and the one you choose for youself will evolve over time, too. I used to sketch everything out. Now I write narratives for how different users will interact with different forms, and how objects will interact with each other as a result of user interactions. Then I code, then I document the code so that I can set it aside without forgetting what I was thinking at the time I wrote it. However, I've only been using that style in that form for about two years or less. Before that it was all sketches on notepads.

Quote:

---

Originally Posted by maurices5000

I'm reading this book OOP Demystified. It seems pretty good. I'm getting a better understanding of OOP.

It says that OOP programmers use flow charts and pseudo code to describe processes. Do programmer still use flow charts? I've only see them used in books that don't use UML. This book does teach some basic UML however.

The book also talks about the use of ER diagrams. However, I've only used those with databases not with OOP. The book doesn't go into detail as to how one uses ERD to describe the relationship between objects in OOP.

I'm just trying to verify some things.

If these things are used, do you have any suggestions as to how i can expand my knowledge? I just want to stick to the basics and build. In the past, i thought one book or so would solve my problems only to bite off to much at a time and get nothing accomplished.

Thanks!

---

ERD in OOP Design is more of like a Class Diagram. Class diagram is similar to ERD but deals with Classes and its relationship with other Classes. I find using both as a good tool to understand the program from a high level point of view.

Flow charts is useful to diagrammatically present a logic that is easier for the programmer to follow. I basically do Flow charts and pseudocode first before doing the actual programming for logic intensive modules.

These diagrams are mainly for documentation of the design purposes, (aside from the comments you place in your code) and if you're still starting up better to just stick with Flow Charts first before moving on to design. Note that Design diagrams make your life easier by outlining what you need to do in your code/implementation already (SDLC).

The basics of OOP are easy you can understand all the terms by reading a chapter about it but if you want to get down and dirty with Design part of your OO program, I suggest you read up on Design Patterns. Knowing the more familiar patterns you'll be able to design your application faster and better, as well as put your OOP knowledge to good use.

Thanks for the comments guys.

Oceanebelle, so you are saying that even though i BARELY understand OOP, haven't even applied the little knowledge i currently know, which are the very basics, that I need to read yet another book on patterns before i can begin to develop an application?

Is the book going to show me how to break an app down into objects?

I'm beginning to think i should do some practice before i start loading my head with more info. I've bought so many books in the past and started reading them, not getting much of anywhere adn getting discouraged.

I plan to design a testing app. My plan was to sit down and try to map out what my objects would be. I've already developed this app in using VB6 (of course with procedural programming). I have a good idea of where the app is going and what is needed. But doing all of this in OOP will be a new experience. I was thinking that i would start the project and just ask questions as i go along. But really, I'm having a hard time deciding waht should be an object and what should not. At least right now. But i want to avoid the spaghetti code of procedural programming.

I'm afraid that if i read another book, i will forget what I'm currently learning. By the time i get finish reading a book on patterns i will have to reread the book on basic OOP. Who's to say that the patterns i learn will be the ones I'll need?

Thanks for the info. I'm really looking for advice.

Yeah, you can only read so much before you apply it or lose it.

Quote:

---

Originally Posted by maurices5000

Thanks for the comments guys.

Oceanebelle, so you are saying that even though i BARELY understand OOP, haven't even applied the little knowledge i currently know, which are the very basics, that I need to read yet another book on patterns before i can begin to develop an application?

Is the book going to show me how to break an app down into objects?

I'm beginning to think i should do some practice before i start loading my head with more info. I've bought so many books in the past and started reading them, not getting much of anywhere adn getting discouraged.

I plan to design a testing app. My plan was to sit down and try to map out what my objects would be. I've already developed this app in using VB6 (of course with procedural programming). I have a good idea of where the app is going and what is needed. But doing all of this in OOP will be a new experience. I was thinking that i would start the project and just ask questions as i go along. But really, I'm having a hard time deciding waht should be an object and what should not. At least right now. But i want to avoid the spaghetti code of procedural programming.

I'm afraid that if i read another book, i will forget what I'm currently learning. By the time i get finish reading a book on patterns i will have to reread the book on basic OOP. Who's to say that the patterns i learn will be the ones I'll need?

Thanks for the info. I'm really looking for advice.

---

ah Sorry for late reply, but I think I have said much already on PM.

You know OOP and got all the terms right but the question is on how to tie them together still remains unanswered. For me, Design Patterns did a good job to eliminate that gap.

Good luck on that book, you're not alone. :wave:

You should read joel on software. Its a "light" book so will not boggle the mind, but it does explain the phenomenom of programmers getting bogged down in planning and never actually doing anything, there is lots in this book that will make you just want to write software rather than worry about design. Most projects that you will engage in as a begginer will have very little planning in them as they are more of a discovery excercise.

I do like pseudo code on the other hand as i have began to use it in my source code rather than leaving TODO: notes all over the place. Another good book on software is code complete 2.

Remember OOP is only a "way" of designing software. Getting bogged down on the acedmics of OOP will break your heart. The best thing to do is write hundreds of lines of code, as you become more comfortable with your chosen language you will begin to develop your own personal organisation and realisation skills.

Hope this helps.

I don't think you should dive in the deep end just yet. You can't understand string theory without having a basic understanding of, for example, the laplace transforms. Similarly, it'll help if you attempt to design a small application first, get it criticized to death by us, and after you're comfortable with the simple, move on to patterns. Chances are that if you're still learning OOP, then going into patterns is only going to bamboozle you further until you practice what you know.