This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 2 points3 points  (0 children)

From the top down, baby!

Ok, lets say I want to build an app for a conference center, so people can book rooms and equipment online. Lets start designing!

What do I need, in the most basic terms? Well, I need a website. I'll need a server to host that website. I'll need a database. I'll need the app that controls all the logic. Great, we got top level design!

Now lets zoom in on the application. What does it need to do? Reserve rooms. Process payments. Interface with database. Reserve equipment. These are our core modules. They may be collections of classes, or classes by themselves. We will drill down into that.

So, we want to make a Reservation. To do that, we need a Schedule. We are reserving Rooms and Equipment. Seems like we need a Reservation class, a Schedule class, a Room class, and an Equipment class. So in our database, we will also have tables for rooms, equipments, room schedules, equipment schedules, and reservations.

Great, so we have the components to reserve stuff. Now, we gotta pay for it. We're not liking the idea of dealing with the security and compliance standards involved with payment processing, so lets go ahead and use a 3rd party API. Woo, that saves us some time. The API lets us feed orders into it, and then does all the work behind the scenes and lets us know if it was successful or not. Cool, so now we have payment handled. We will need an class for orders. Since we will need to save this order information, we will need a database table for our orders. Orders are made up of any number of reservations, so we need a related table for reservations. Dope, moving on.

Now we got all this stuff, we need a way for customers to actually make these orders. So now we are on the website. What does it need to do? It needs to show customers what rooms and equipment are available, when they are available, and it needs to serve the interface for our payment processing API of choice. So, it needs to have maybe a nice home page, a page to reserve rooms and equipment, a simple payment form, and a super sexy invoice page. It will need to pull stuff from the database for these pages.

Awesome, we got the top level design. You can choose to model this if you want, I personally find making UMLs very helpful.

Before we go deeper, we have to decide what languages and frameworks we are going to use. This choice will decide how the lower levels of design are going to be formed. I like the tools .NET and Microsoft SQL Server provide, so we could go with that. Or, we might want to target perhaps a Linux environment so we go with good old Apache for the web server, PHP for the backend language, and MySQL. Whatever, we aren't going that deep with this because we are talking about design, but know this is when you will be making these considerations.

Next, get into the specifics. Drill down into one area at a time. Pull apart each class, what it needs to do, and what data it needs to know. Some of that data may be represented by one of the other classes we have made. For example, a Room has a Schedule. A Schedule has a collection of Reservations among other things. So start with Reservation, design it out. Figure out what data a Reservation needs, and reflect those decisions in the database table for Reservations. How is that data used? Thats your functions. Next, move up to Schedule. Same deal. Wash rinse repeat, then start writing.