Develop Reference

What to do after writing the user requirements document?

Suppose I have to develop a Desktop Application using Java SE. I have finished writing User requirements document. In this document, I mentionned the functionnalities of my futur application. I analysed the needs of the user and established What the ideal application has to perform.
Now, I have to conceive the architecture of the application and ddetailled conception of the app. This is what I don't know how to do ?
I have an idea, which is as follow : elaborate a use case diagram, then for every use case, make an sequence diagram finally produce a class diagram from which I can generate the code.
Is this correct ? How about using a database management system at which level I add the use of DBMS ? from the first uml diagramme ?
please any help is a welcome.

Well you know the functions you will implement and you know the requirements. While at this point you should know or infer some database requirements you don't have the whole picture yet. If you want to do an iterative software development you can start with whatever you feel you got more to progress with, then go back to your other tasks and work in increments. Because you are doing an iterative process you will be erasing bits here and there, polishing your work as you go.
To work sequentially, you'd finish all the analysis documentation before doing design, and that before touching code. Initial databases can be generated from java classes (beans), so that's when that comes in.
Under your chosen methodology the wiki link you provided lists what it is expected to be done in order. For the part of high level design, which you claim to have problems with, you'll want the appropriate UML diagrams, use components for modules/software architecture.
Because it is high level design keep it high level, don't delve in details. eg for a videogame: Graphics, Audio, Network, etc, and how they will interact (Interfaces), don't define anything smaller, no classes, no methods, main packages/libraries can be done. For hardware architecture you may use a deployment diagram I guess, have each cube represent the hardware of the boxes that will run your code, you aren't prepared for deployment but you can make changes to your initial proposal next iteration if you need.
Database design is at the end, but the wiki specifically tells you to only define tables, don't define columns yet. You will define that in the low level detail phase.

Java Messenger : save message archives on the computer

I am doing a Java Messenger for people to chat and I an looking for a way to record the message archives on the user's computer.
I have 2 possibilities in my mind :
To Save the conversations in XML files that I store in my documents folder.
To use SQlite, but the problem is that I don't know how it is possible to integrate it to my setup package and I don't know if it is very useful.
What would be the best solution for you ?
Thank you

Another option is using JavaDb, which comes for free with Java 6 (and later versions)
Before you make a choice, you should think about questions such as:
presumably you want this transparent to the user (i.e. no admin involved)
is performance an issue ?
what happens if the storage schema needs migration
do you need transactionality (unlikely, I suspect)
etc. It's quite possible that even a simple text file would suffice. Perhaps your best bet is to choose a simple solution (e.g. a text file) and implement that, and see how far it takes you. However, provide a suitable persistence level abstraction such that you can slot in a different solution in the future with minimal disruption.

I would go for the XML files as they are more generic and could be opened outside your messenger with more or less human readable format. I use Pidgin for instant messaging and it saves chat history in XML. Also to read the history from your application you can transform then easily in HTML to display it nicely.

If you use JAXB, converting Java objects to/from XML is very easy. You just put a few annotations on your classes, and run them through a JAXB marshaller/unmarshaller. See http://docs.oracle.com/javaee/5/tutorial/doc/bnbay.html

Use google's protocolbuffer or 10gen's bson. they are much smaller and faster.
http://code.google.com/apis/protocolbuffers/docs/javatutorial.html
http://bsonspec.org/
One issue is these are in the binary presentation and you might want to make the archive transparent/readable to users

Loading facebook's big text file to memory (39MB) for autocompletion

I'm trying to implement part of the facebook ads api, the auto complete function ads.getAutoCompleteData
Basically, Facebook supplies this 39MB file which updated weekly, and which contains targeting ads data including colleges, college majors, workplaces, locales, countries, regions and cities.
Our application needs to access all of those objects and supply auto completion using this file's data.
I'm thinking of preferred ways to solved this. I was thinking about one of the following options:
Loading it to memory using Trie (Patricia-trie), the disadvantage of course that it will take too much memory on the server.
Using a dedicated search platform such as Solr on a different machine, the disadvantage is perhaps over-engineering (Though the file size will probably increase largely in the future).
(Fill here cool, easy and speed of light option) ?
Well, what do you think?

I would stick with a service oriented architecture (especially if the product is supposed to handle high volumes) and go with Solr. That being said, 39 MB is not a lot of hold in memory if it's going to be a singleton. With indexes and all this will get up to what? 400MB? This of course depends on what your product does and what kind of hardware you wish to run it on.
I would go with Solr or write your own service that reads the file into a fast DB like MySQL's MyISAM table (or even in-memory table) and use mysql's text search feature to serve up results. Barring that I would try to use Solr as a service.
The benefit of writing my own service is that I know what is going on, the down side is that it'll be no where as powerful as Solr. However I suspect writing my own service will take less time to implement.
Consider writing your own service that serves up request in a async manner (if your product is a website then using ajax). The trouble with Solr or Lucene is that if you get stuck, there is not a lot of help out there.
Just my 2 cents.

Best programming process for creating a graphically-complex Java Swing Application?

I'm starting a fairly complex Swing application that heavily graphics-oriented with about 1000 separate jpegs, 30+ different forms, and timers keeping track of the rate of user-interactions throughout.
My question is from a practical programming perspective, after I've already written a storyboard for the entire project and got it approved by the client, where's the best place (code-wise) to begin programming this massive project and in what order should I program the elements?
(Example Answer: first begin coding the declare and init statements of all the necessary pieces, then write skeleton versions of all the methods, then deal with swing design and layout manager (gridbag), and then deal with Events and Listeners)
Thanks for the advice everyone, oh and btw I really love StackOverflow!

You're describing a "waterfall" development approach - completing some level of the program first, then completing the next level etc. It's indeed one possible approach, but many people find it so called tracer bullet approach better; first make something functional, then learn from it, adjust what's needed and proceed. It's especially useful if you're working with a client, because by showing prototypes you can get feedback and avoid misunderstandings.

I'd pick up a book on TDD and even if you're not going to write automated tests, it will be full of good advice on how to approach your project.
After that I'd pick a single piece of functionality that slices all the way through your application vertically and implement that end-to-end. This should allow you to get any infrastructure/frameworks in place and spot any gotcha's that may get thrown up out of your design.
If your client has the time free, show them each piece of functionality along the way and make sure that every piece you do adds some value to the product.
--EDIT
In addition I'd take a look at using a graphical designer for your screens instead of using the GridBagLayout. That will just waste time and can quickly become a maintainence nightmare when changing screens. I personally prefer the ones that work in a resource file type way, where the screen is essentially "compiled" and you just load it into your code

I prefer writing the UI so, that first I write (using TDD) the backend classes which implement the behaviour of the UI, without any dependencies to the presentation of the UI (i.e. without Swing or any other UI library). After that I write a thin presentation layer with an UI library, where all the event handlers etc. delegate to the UI backend (they should be just one-liners without any logic). The benefit of this is that you can easily write tests for the UI, which in turn makes it easier to change and maintain the UI. See the links at http://martinfowler.com/eaaDev/ModelViewPresenter.html for more details.
At a higher level, first implement the features which will produce the most value to the users. Try to get something to show as early as possible, so that you can get feedback from the users and improve any deficiencies in the UI. You can fake most of the background services (for example the database and business rules), so that the UI can be used, even though it does not yet really do anything.

I think mad-j has the words of wisdom.
Don't concentrate on the 'all'... identify sections/components/modules and deliver those. Then move on to the next and the next. This is called Iterative and Incremental Development (a response to the weaknesses of the waterfall model)!
This will also allow you to create tools and frameworks which should make your development easier and faster as you move along.
This will allow you to show your clients functional parts early. But a word of advice! Your client will more than likely keep changing its requirements, changing the GUI, changing its mind, etc. I've seen entire projects fail due to these continuous changes. It is out of the scope of this question to mention any more on this, but please be aware that it more than likely will happen and be prepared to deal with it!
If you and the client have functional parts, they can be tested immediately rather than testing one huge system.
By completing functional parts iteratively will probably allow you to work at every layer, on most API's using most tools and technologies. The advantage of this is that it will allow you to identify the complexities early. It is those complex areas that render this following statement true:
The first 90% of the code accounts for
the first 90% of the development time.
The remaining 10% of the code accounts
for the other 90% of the development
time. --Tom Cargil
Identifying, acknowledging and understanding those complex areas will allow you to manage your risks and alter your efforts and resources more effectively.
Good Luck,
Jeach!

As mentioned by MrWiggles, you may want to look into using a UI builder.
If you're looking at writing many forms, and it looks like the form data can match nicely to some javabeans, you may want to think about creating some framework panels first.
If you can create some simple base classes that take care of the wiring (syncing the fields to the beans and vice-versa), it'll save you a lot of work.
You may even want to set up some panels that will "auto create" fields based on beans. Just pass in a bean and the panel creates itself. The trick there is specifying layout for the fields, and dealing with fields that have fixed values, validation, etc. (Fixed values can be dealt with using javabean property editors - see http://javadude.com/articles/propedit/index.html.
If you're set on using Swing (eclipse RCP is nice, btw), you might want to look at the Swing Application Framework (https://appframework.dev.java.net/). If not using it directly, it may give you some ideas on how to set up bindings.
Hope this helps a bit

Are you really sure of Swing? Eclipse RCP is much better and flexible starting from EMF and going on
Anyway with Swing, first I'll prepare an XSLT template of all: common code routine and other common pieces of common to bring then them in abstract and interface classes, ORM patterns you use.
Then I'll design a common UI scheme, this "xslize" too.
After all with ANT XSLT processor I'll prepare a complete build procedure upon your specs.
P.S.
I made similar projects for simple web and swing cruds just before 2001, and if you use some peculiar UI designer you can also nest or write with xslt every specs without putting dirty code in your ui raw concepts, so when I make/add remove features on all or singular piece of code, 30 seconds maximum for full rebuild of ALL, of course you must "XSLIZE" all using also many xslt overrider/import.

Creating dynamic data entry forms

I have a small project where I would like to generate dynamic data entry forms with a little bit of logic behind them.
A simple use case might be
a Football resulting form, so you have a button for a goalscorer, and when clicked the user will be prompted for a player. The form will then send a message (probably to a webservice, but maybe a JMS queue) with the event data. eg Barcelona, Goal, Henry.
Then I want to create a similar form for tennis...
My idea was that I would create a webservice, where you define business logic. (events, components, actions you take etc.) Initially I thought I would send the sport definition from the webservice in xml. Then write an app to parse the xml and dynamically create the data entry screen.
I was initially thinking of writing a webservice and returning a xml data. (which will look awful) the rendering technology could then be flex/ flash and be a thin client.
Then I thought it would just as easy to create the forms as a java app using the swing application framework and that was the way to go.
Then I thought, well, rather than write a xml schema to describe the java forms, can I just serialise a java class and send that across the wire.
Once on that path, I am now wondering if should just a java framework, and the dynamic forms become class that are called by reflection.
I would love feedback on the above approaches, and how people on stackoverflow would solve this problem.
thanks
David.

I would avoid serialisation because it is a bit fragile, difficult to do safely and difficult to diagnose.
You say it's a small project, so does the metadata really have to pass from client to server? Would you not be much better off very simply writing the metadata (really code) as Java code?
(FWIW, my first commercial Java project was creating forms dynamically from a database specification (with regular additions). Previous to that I working with C++ running an interpreter for training systems. In both cases I would now (and for the last decade), have written them as Java. Don't be put off by people mumbling disapprovingly about "hardcoded".)

I would consider XForms as well. It allows you to define both the data model and the UI as XML, and all you need to render it on the client side is a web browser. I assume the event would be submitted to a remote server, which makes the web browser as a natural choice.
This would enable you to generate the UI on the server based on what kind of sport event the user wants to report about, so you can easily add new forms, fix bugs, etc. without ever having to update the client software.
By the way, I don't understand your concerns about using XML. In my opinion it's a viable option for your use case.