Tips for designing software on paper.

Class Design, Method Design, etc.

Page 1 of 1

12 Replies - 2338 Views - Last Post: 23 January 2010 - 04:19 AM

#1 papuccino1  Icon User is offline

  • His name was Robert Paulson.
  • member icon

Reputation: 63
  • View blog
  • Posts: 1,121
  • Joined: 02-March 08

Tips for designing software on paper.

Posted 03 June 2009 - 07:09 PM

What's up guys.

I was just wondering how some people go about designing their code on paper before actually coding it.

For instance, how do you know what to put inside of a class. How do you know that attribute doesn't deserve a class of it's own.

What steps do you follow in building software.

I'm more interested in the actual process you follow than the theory behind it.
Is This A Good Question/Topic? 0
  • +

Replies To: Tips for designing software on paper.

#2 SixOfEleven  Icon User is offline

  • using Caffeine;
  • member icon

Reputation: 945
  • View blog
  • Posts: 6,342
  • Joined: 18-October 08

Re: Tips for designing software on paper.

Posted 04 June 2009 - 07:07 AM

View Postpapuccino1, on 3 Jun, 2009 - 08:09 PM, said:

What's up guys.

I was just wondering how some people go about designing their code on paper before actually coding it.

For instance, how do you know what to put inside of a class. How do you know that attribute doesn't deserve a class of it's own.

What steps do you follow in building software.

I'm more interested in the actual process you follow than the theory behind it.


It depends on the project and if you are working as part of a team. If you are working on your own you can take a few short cuts and skip a few steps but that is not always a good idea. There are three main steps that I try to follow. Analysis, design and programming. This is a little simplified because the entire process has had entire books written about it and I spent an entire third year semester studying the concepts of object-oriented design and analysis. There are also classes on the entire software life cycle.

I tend to think about the project. What I exactly want to do and the scope of the project. I will try and walk through creating an object-oriented version of the Asteroids game.

The first thing I try to do is think of all of the objects that are necessary in the project, using an IS_A question. For example, when creating an object-orient version of Asteroids you know that you will need a sprite class for the objects in the game. You might want a class for the player.

Then I would think if having the various object, asteroids, bullets, the ship and the UFO using an IS_A relationship. A ship IS_A sprite. An asteroid IS_A sprite. A bullet IS_A sprite. A UFO IS_A sprite. So, the asteroids, bullets, ship and UFO would inherit from the sprite class.

Then I try to think about what attributes the object I'm trying to model has using a HAS_A. For example, a sprite HAS_A texture, location, velocity, etc. Then, I try to think what actions the object preforms. For example, a sprite draws itself, it updates itself, it checks for collisions. Then I would think of the inherited classes if they would have to override any of the actions or have any actions of it's own or using a HAS_A for the inherited classes.

Use cases are a good way to help with the above process. For example I would take the ship.

User rotates the ship
The ship rotates left
The ship rotates right

From that you know that a ship has an attribute and an action. It will have a rotation attribute and an action to rotate the sprite.

Hope I didn't confuse you, I'm still not quite awake yet. :D
Was This Post Helpful? 1
  • +
  • -

#3 papuccino1  Icon User is offline

  • His name was Robert Paulson.
  • member icon

Reputation: 63
  • View blog
  • Posts: 1,121
  • Joined: 02-March 08

Re: Tips for designing software on paper.

Posted 04 June 2009 - 08:13 AM

You didn't confuse me Jamie. That's some great methods you got going there. I'll try to use them in my current project. Right now I'm just writing things down in paper. In about a week after some thought, I'll start coding it.

Does anyone else have some design steps they take?
Was This Post Helpful? 0
  • +
  • -

#4 lesPaul456  Icon User is offline

  • D.I.C Addict
  • member icon

Reputation: 173
  • View blog
  • Posts: 729
  • Joined: 16-April 09

Re: Tips for designing software on paper.

Posted 04 June 2009 - 12:03 PM

I follow a lot of the same steps as SixOfEleven when programming games.

Usually, for software applications, I start by looking at what my application will do. I then think of how I want to go about accomplishing this task. This process is know as "Analysis". Analysis is basically the process of understanding and detailing the the problem you are trying to solve. The length of the analysis period depends on the complexity of the problem. Some times the analysis period can take weeks, or even months. One technique that I use is to create what are called "use-case scenarios", where you describe in detail how the application will work. Another thing you might do during the analysis period is to write a specification of your program's requirements.

Next comes design time. The "Design" process is the actual planning of your solution. Once you analyze the problem, you design the solution. This is when you start imagining the classes you will use, and their relationships. There are may design techniques you can use, but I personally usually write down some pseudo-code for each class. Some times, I even draw out diagrams of the classes, with their possible members, so that I can literally see the relationships between each class, and the relationships that occur within the classes.

I think when it comes to design and planning, the process that you take is impacted by several factors, such as the size of your team, your experience and background, and your training. For example, someone like SixOfEleven, with alot of experience and training, probably has a very efficient (Borg-like ;) ) approach to design. I, on the other hand, take a lot of time in the design process, and then I still find myself changing the actual code once I get started.
Was This Post Helpful? 0
  • +
  • -

#5 SixOfEleven  Icon User is offline

  • using Caffeine;
  • member icon

Reputation: 945
  • View blog
  • Posts: 6,342
  • Joined: 18-October 08

Re: Tips for designing software on paper.

Posted 04 June 2009 - 01:34 PM

View PostlesPaul456, on 4 Jun, 2009 - 01:03 PM, said:

I think when it comes to design and planning, the process that you take is impacted by several factors, such as the size of your team, your experience and background, and your training. For example, someone like SixOfEleven, with alot of experience and training, probably has a very efficient (Borg-like ;) ) approach to design. I, on the other hand, take a lot of time in the design process, and then I still find myself changing the actual code once I get started.


The complete software development cycle is long for complex projects. The better you plan your solution the better off you will be. One of my favorite sayings is:

If you fail to plan, plan to fail.

For big, complex projects, like with the RPG I'm working on, the better you plan the easier it will be to implement your solution. I also do a lot of planning when I'm writing books.

For simple projects, I do have a simple, dare I say, efficient method that I follow. I also follow a simple method when I'm planning articles or short stories.

*edit*
I forgot to add that I have a method of planning tutorials.

This post has been edited by SixOfEleven: 04 June 2009 - 01:37 PM

Was This Post Helpful? 0
  • +
  • -

#6 KeyboardKowboy  Icon User is offline

  • D.I.C Head
  • member icon

Reputation: 20
  • View blog
  • Posts: 142
  • Joined: 15-December 08

Re: Tips for designing software on paper.

Posted 09 June 2009 - 09:49 PM

If you haven't already taken a course or read a book on this topic, I recommend you do so. It may seem monotonous and unimportant at first, but the insight you gain is tremendous. Research these topics: Systems Analysis and Design, Objected-Oriented Analysis and Design. These topics dive into the points that have been previously mentioned.

I'd also like to add that the Analysis and Design phases are part of the overall SDLC (Software Development Life Cycle). They call it a cycle for a reason! Long gone are the days of the procedural/traditional waterfall approach to the SDLC. The phases are now cyclical, and continue to iterate through each phase over and over for the life of the software system. Trust me... this process works when implemented properly.

As was also discussed... while researching the Systems Analysis and Design, OO A&D, you will become familiar with model based graphical planning tools. Use Case Diagrams, State Charts, Spiral Models, Problem Domain Class Diagrams, Sequence Diagrams, etc. Use them! Not only will they help you kick start the system, it also makes maintenance and modifications in the future less troublesome.

And always remember.... The 7 P's
Proper Prior Planning Prevents Piss Poor Performance
Was This Post Helpful? 0
  • +
  • -

#7 SixOfEleven  Icon User is offline

  • using Caffeine;
  • member icon

Reputation: 945
  • View blog
  • Posts: 6,342
  • Joined: 18-October 08

Re: Tips for designing software on paper.

Posted 10 June 2009 - 06:37 AM

There are two more things you should think about when designing software:
KISS and GIGO

Keep It Simple Stupid

Garbage In Garbage Out
Was This Post Helpful? 0
  • +
  • -

#8 Theaegd  Icon User is offline

  • Hater & Lover

Reputation: -125
  • View blog
  • Posts: 944
  • Joined: 15-August 09

Re: Tips for designing software on paper.

Posted 17 August 2009 - 10:35 AM

I would never do my code on paper first. it is a waist of time and it is more difficult plus you would have to write it all over again on the comp
Was This Post Helpful? 0
  • +
  • -

#9 Core  Icon User is offline

  • using System.Linq;
  • member icon

Reputation: 774
  • View blog
  • Posts: 5,097
  • Joined: 08-December 08

Re: Tips for designing software on paper.

Posted 17 August 2009 - 11:32 AM

Quote

I would never do my code on paper first. it is a waist of time and it is more difficult plus you would have to write it all over again on the comp


Kind of an old topic but anyway...

Nobody says you have to do the code on paper. Moreover, it is irrational to write code on paper. One important skill every developer should have is planning - on paper or on a whiteboard, using pseudo-code or UML. Sometimes it is just faster to show some ideas on paper (UI concepts, data flow etc.) rather than directly implementing them or building an UML diagram.
Was This Post Helpful? 0
  • +
  • -

#10 SwiftStriker00  Icon User is offline

  • No idea why my code works
  • member icon

Reputation: 432
  • View blog
  • Posts: 1,596
  • Joined: 25-December 08

Re: Tips for designing software on paper.

Posted 25 August 2009 - 04:40 AM

Scratching out a little sudo code or some method stubs goes a long way to be able to see what your code will look like before you start coding. Also can prevent you from writing redundant code. Since I'm a visual learner, I can very quickly understand a system from looking at UML diagrams.

It doesnt really matter what you do, as long as you organize your thoughts somewhere (notepad.exe, a whiteboard, a mirror, paper)
Was This Post Helpful? 0
  • +
  • -

#11 MentalFloss  Icon User is offline

  • "ADDICTED"[2:5]
  • member icon

Reputation: 526
  • View blog
  • Posts: 1,397
  • Joined: 02-September 09

Re: Tips for designing software on paper.

Posted 05 September 2009 - 04:51 AM

This paper should give you a good idea of the process:
http://sites.google....ming-assignment

The author uses some colorful langauge, so caveat lector.

I'm not really in the mood to write out my own process. Maybe next time.
Was This Post Helpful? 0
  • +
  • -

#12 Grapevine  Icon User is offline

  • D.I.C Head

Reputation: 2
  • View blog
  • Posts: 55
  • Joined: 26-October 09

Re: Tips for designing software on paper.

Posted 01 November 2009 - 05:53 PM

Hey whats up?

I actually use my treo a lot when im on the road but its the same concept I guess...

I actually write it in a list format. There's hardly any organization on my part but I can understand it which is all that matters.

For example (I would write the below for a project Im working on):

My Web Browser project:

This is a simple project to test some new methods I learned and to get me more familiar with the WebBrowser control.

- Menu Items:
+ File
- Open
- Save
- (Seperator)
- Page Setup...
- Print
- Print Peview...
- (Seperator)
- Options...
- Exit
+ Edit
- Cut
- Copy
- Paste
...... (Etc....)


- Features
+ Make sure.....(blah blah...)
+ I want to add a lock symbol in the webAddressTextBox to show wether or not the website is encrypted
- maybe include a small panel to display the security details...
+ enable all navigation controls (back, forward, stop, refresh...)...
...... (Etc...)



- Methods
+ Display the current Time in the status bar
//Display current time
private void CurrentTime()
{
currentTimeStatusLabel.Text = System.DateTime......
}

***Create a timer to update the currentTimeStatusLabel

................

And so on. I just write notes to myself and when I actually begin, I worry about the more major things. This is usually just when im on the the road and I have an idea or think of a new feature for something....

later
Was This Post Helpful? 0
  • +
  • -

#13 KewlBeans  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 15
  • Joined: 12-December 09

Re: Tips for designing software on paper.

Posted 23 January 2010 - 04:19 AM

Not nessecarily on paper, but I think in order to write any complex system, you have to do some planning.

Sometimes its just a whiteboard where myself and a few peers will write out our thoughts and organize them until we agree.

But mostly I would organize with the Visual Studio Class Designer or just Flowcharts using Visio. There are alot of tools to help you visualize your system before you implement. A little planning now will save you hours of coding and recoding later.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1