aspose file tools*
The moose likes Agile and Other Processes and the fly likes How do you write an application? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "How do you write an application?" Watch "How do you write an application?" New topic
Author

How do you write an application?

Matt Kidd
Ranch Hand

Joined: Jul 17, 2002
Posts: 260
(I didn't know where to put this so I guessed here since this is the closest to software methodology here at javaranch)

Thats a pretty plain jane question isn't it....and pretty wide open since I could easily be talking about a "Hello World" application...but I'm not. I'm talking about how does a piece of software, for example say Firefox, Thunderbird, or any other downloadable application, go from being an idea to a design to code and something actually usable.

I had a software engineering course in school but that was Spring of 2000 and the industry isn't anywhere the same (I'd even argue that is changed quite a bit right when I graduated but thats a rant for some other time) and even that course didn't stress actual coding of the system we designed. So as it stands I have a CS degree without having written a large program (probably not to uncommon in the late 90s....I hope). I'd like to change that.

Now i have a few ideas for stuff I'd like to write, with on in mind in particular, but I don't know how to these ideas to actual production code. I'm thinking of the methods and ways to accomplish particular tasks but I'm not bringing it all together.

What I"m looking for is a step-by-step process that hopefully doesn't get muddied with the new methodoligies like XP, even though that would probably make me more current I'd rather save that for the big project I have in mind.
Steven Bell
Ranch Hand

Joined: Dec 29, 2004
Posts: 1071
I think that's the million dollar question. There really is no 'way' to write an application. The basic steps are to gather 'all' the requirements, what it does, what it looks like, what is it's purpose, identify the problem. Then break that problem down into pieces, break those pieces into pieces, until you have small enough peices to work with. Build the small pieces and pull them together. (As you break them down you would need to identify how they will interact, Interface, messaging, whatever).

One thing I think nearly all developers have found out the hard way is that getting the requirements right can make or break the app (or at least be the cause/prevention of alot of headache).
Karen Baog
Ranch Hand

Joined: Mar 02, 2005
Posts: 120
Scope your requirements. Draft a Software Requirements Specification.
To start with, the top-level requirements are extracted from the contract.


amerzil co-ed student<br />"Praise be the Code"
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Steven Bell:
One thing I think nearly all developers have found out the hard way is that getting the requirements right can make or break the app (or at least be the cause/prevention of alot of headache).


Paradoxically, what many also have found is that it's nearly impossible to get "all the requirements fully right" before starting to code.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Matt Kidd:
I'm thinking of the methods and ways to accomplish particular tasks but I'm not bringing it all together.


Tell us more about that: what are thinking of, and in which ways do you struggle with bringing it together?


What I"m looking for is a step-by-step process that hopefully doesn't get muddied with the new methodoligies like XP


Not sure what you have against XP. One step-by-step process I know of is ICONIX. Sadly, I don't know wether there is a good description of it available.

Anyway, there is only one thing that I think really applies almost universally: every successful big project started as a successful small project.
Matt Kidd
Ranch Hand

Joined: Jul 17, 2002
Posts: 260
Originally posted by Ilja Preuss:


Not sure what you have against XP. One step-by-step process I know of is ICONIX. Sadly, I don't know wether there is a good description of it available.

Anyway, there is only one thing that I think really applies almost universally: every successful big project started as a successful small project.


"Tell us more about that: what are thinking of, and in which ways do you struggle with bringing it together?"

(for some reason that part didn't quote)

Take my calculator app I want to do for example. Conceptually I can figure out the interface and how I want to have a basic calculator then add additional functionality like trig functions and converting of degrees or math in over degrees like radians. Then I learned there are multiple ways of computing pi so I thought about adding that as a cool little visual (just click a button and watch them go see which is faster sort of thing). Well now that I have this interface I get stuck connecting it to the logic but the logic I can figure out sort of in that I know that I'll need methods for multiplication, figuring out a square root, or raising a variable to a specific power. But I can't get how to get from the interface concept to the coding of the actual logic or how its all packaged.

Actually I think that may be it. I recall my advanced OOP course I had that I got completely and totally lost with how it was packaged. I didn't know what was where as it seemed to me that the program could start in any of 3 files and there was a lot of redundancy (my memory is bad forgive me...I'm probably making myself sound better than I actually was) with the way it was packaged and generally didn't make much sense. It also probably had to do with how for everything I've coded I've gotten a grasp of how the whole thing works before I started coding usually using some UML diagram.

As for XP, I have absolutely nothing against it aside from it being this big huge black box that I don't know what is inside of it and appears to be completely and totally unweildly. Yet I'm sure once I sit down with the book I have at home I'll realize its just another software cycle like waterfall or spiral.

I hope that gave you a better idea. I'll go looking for that ICONIX too.
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Matt Kidd:

Well now that I have this interface I get stuck connecting it to the logic but the logic I can figure out sort of in that I know that I'll need methods for multiplication, figuring out a square root, or raising a variable to a specific power. But I can't get how to get from the interface concept to the coding of the actual logic or how its all packaged.

Possibly what's missing here is that there is a whole layer of code that deals with the user interface, and not with the functionality.

If you want a graphical program, you might try picking up a Swing book and trying an example from it; if you want a web application, you'll need to create the HTML and write code to parse input from the user and convert your output into an output page. Often there's more code involved in the user interface than there is in the core functionality.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
You might take a look at Ron Jeffries' Adventures in C# (It's close enough to Java that you can read it.) It's essentially a diary of building an XML editor. I've read some installments on his website (http://www.xprogramming.com/xpmag/acsIndex.htm) that were very interesting.

Robert Martin's Agile Software Development has a neat case study building a payroll system that should give you some ideas about getting requirements up front and evolving as you go.

Both of these have a sense of watching over the master's shoulder. Certainly one way to learn something.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Matt, if I understand you correctly, your main problem is with how to structure your code?

If I got that right, I highly recommend the book Stan already suggested. It discusses the forces, principles and practices behind OO as a tool to structure your code at great length, with many examples.
Matt Kidd
Ranch Hand

Joined: Jul 17, 2002
Posts: 260
Ilja, which book were you speaking of?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Matt Kidd:
Ilja, which book were you speaking of?


Robert Martin's "Agile Software Development": http://www.coderanch.com/t/93457/Book-Reviews/Agile-Software-Development-Principles-Patterns
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I'm pretty sure Ilja is referring to Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin (which is indeed a great book for explaining some practices and principles for implementing good object-oriented designs).


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How do you write an application?