I'm developing an API
So what's the problem in defining the API using classes and interfaces and documenting what each method should do?
Example:
/**
* Esta classe deve implementar comportamentos comuns a todos os animais
*/
abstract class Animal {
/**
* Consome uma implementação de {@link Comida}.
* @param comida O animal pode rejeitar a comida se não for do tipo que ele gosta
* @throws AnimalNaoPodeComerIssoException
*/
abstract void comer(Comida comida);
}
/**
* Interface implementada por animais que voam.
*/
interface Voador {
/**
* Desloca o animal até o local especificado.
* @param local Onde o animal deve pousar
*/
void voar(Local local);
}
/**
* Detalhes sobre como implementar um Pombo...
*/
class Pombo extends Animal implements Voador {
//detalhes sobre como implementar os comportamentos específicos
}
Anyway, everything goes to Javadoc, then it is enough for the programmer to follow what is there.
What I really want to do is to manually write everything the API should have and format it into documentation before creating the code
Use Word or any text editor. Perhaps a collaborative tool like Confluence (note: I work for Atlassian) is better for facilitating the work of several people and versioning of the document.
Specific UML diagrams can be added wherever you need them.
A place where you have fields for classes, variables, methods, enums, etc.
Create a table as a template. You do not need a tool for this, just have a minimum of discipline to document.
The UML programs are very bad, it is horrible to have to represent graphically (squares and arrows everywhere)
I agree that most are horrible. The best I know of is Enterprise Architect, which I used a few times to create architectural documents for new systems that were to be developed.
However, saying that you are confused because of the program is not true. You probably need to become more familiar with UML and with the tool.
With UML because you do not need to represent 100% of the program in diagrams, just the most important concepts.
With the tool because you can distribute the objects in different diagrams for each use case. Trying to model everything in a giant diagram is not good practice.