Porting application from Java to ObjectiveC/Xcode

Ignoring whether you have documented Java code or not, it looks as if you are asked to write a Cocoa application without having a proper design in place. Not a good idea. On the other hand, why would you want a formal documentation of the Java code? It is going to be thrown away, isn't it?

0. Start with the design documents that were created for the Java application (although I have an inkling that you will come up empty )

1. Document _all_ persistent data, all interfaces to the outside (data sent to or received from the application), preferences setting etc.

2. Decide whether you want to keep the same format for persistent data, or whether you just want to be able to import it once. In that case document how you want to store data in the future. You may decide to use CoreData for example if that is helpful from performance and scalability point of views.

3. Document the user interface as it is, then decide which parts of the user interface need to stay as they are, which can change but don't have to, and which should change. It's completely pointless to document the Java code for this, because none if it will stay anyway.

3. Design how you will represent the data in Cocoa.

4. Start with code that reads and writes persistent data correctly. When that works perfectly start adding UI to manipulate this data. Management doesn't know how software development works, they believe that when they see something, that's the software. Manage their expectations by not having more percent of the UI finished than of the application itself.

 

I also highly recommend that you document not just the design, but also the requirements. Once you and your stakeholders have a shared understanding of the requirements, you can prioritize them.

Time and budgets are ALWAYS tight. So when you reach the limits of your alloted time and budget (and you know you will), all stakeholders should know ahead of time which features/requirements are highest priority (i.e., "must-have" features) and what can be added onto your new code base later (i.e., "would-like-to-have" features).

 

And if something is found, it may be out of date.

He needs to write down business rules that may be revealed in the code.