Modelado de Software

Que tal:

Si programas orientado a objetos, Argouml te puede ayudar, lo puedes bajar de aqui

Los diagramas que generalmente utilizo son:
Diagrama de secuencia.
Diagrama de clases.

Para mostrar que interaccion tendra el software, algunos utilizan los Diagrama de casos de uso, pero prefiero redactar los casos de uso.
Algo que te puede ayudar mucho, es diseñar la interfase de usuario con un editor vectorial, por ejemplo Inkscape.
Puedes agregar comentarios a las clases y metodos mientras estas diseñando/codificando el software y crear la documentacion de la api con javadoc.

Necesitas un libro base de Ingeniería de Software como este ó uno de modelado UML y Patrones como este

Debes identificar los digramas que presenta el UML y en que estan clasificados para que entiendas cuales usar y en que momento. Con que comprendas la naturaleza de cada diagrama y su clasificación creo que es suficiente para comenzar a hacer diagramas, y para eso te ayudarás de los libros recomendados.

Para el manual de usuario final, no debe de ser algo tan complicado. Piensa en algún manual de usuario que hayas leído y que te haya gustado y hazlo similar.

A nadie nos gusta leer y leer para poder usar un producto, entonces algo como un brochure o así con imagenes esta muy bueno, es sencillo y es mucho más efectivo.

Para la documentación del programador. Lo mejor es también ser efectivos.

1 diagrama de arquitectura como este:

Que sirve de referencia para saber que usa la solución

N ( no quieres describir lo que ya pasa en el código, sino cuales son las interacciones entre partes y/o modulos )

Y pues ya, tus casos de uso donde describas que hace el sistema y/o que debería de hacer.

Yo no agregaría diagramas de clase. Es muy fácil que se pierdan sincronía con el código, además para eso está el código mismo.

Recuerda hacer tu código fácil de entender.

El libro Uml y patrones de Craig Larman es muy bueno, lo recomiendo ampliamente(deberia ser un libro obligatorio para los programadores), aunque si quieres estudiar especificamente UML buscate el de UML gota a gota de Martin Fowler.

vientos empezare aplicando los consejos que me pasaron y bucare los libros que me recomendaron..,

ahora entonces asi va mi idea.. el manual de usuario final ps sera sencillo como los manuales X de algun programa..
un diagrama de arquitectura creo que si seria optimo ta facil de hacer xD.. y se explica bastante mas que un UML .. bueno supongo.
en el caso del diagrama a bloques solo era para mostrárselo a mi maestro para decirle cosas como...

mire aqui entraran los datos de las lamparas y dara este resultado cosas asi... pregunta .el diagrama a bloques esta bien para ese caso?

la onda o mi idea del diagrama de bloques es para explicar mi idea antes de empezar a programar algo o para decir esto hara el programa..
por que supongo que un diagrama de arquitectura o UML ya se haria cuando esta listo el programa.. digo es asi?--

o con que metodo puedo explicar el programa antes de crearlo ya casi tengo todo sobre papel ideas y todo eso, nada de algoritmos , digamos que tengo como un mockup mental jaja..

de echo pensaba hacer un mockup pero eso nada mas explicaria lo bonito o como se veria el programa no como funcionaria..
no se si estoy mal orientado o ya me estoy desviando .

Creo que el mockup es para mostrar el funcionamiento, encontre esto , creo que te va ayudar mucho.

Un buen reto si quieres aprender:
Con el balsamiq (o a lapiz), crea el mockup tratando de que sea el diseño final, es decir, verifica varias veces la funcionalidad.
Si vas a guardar la informacion en una base de datos, diseña las tablas.
Genera las clases.
Escribe los algoritmos.

Junta todo y has el ejecutable y verifica como te quedo, se lo puedes mostrar a alguien que no sepa mucho de computadoras, para ver si entiende como trabaja la aplicacion, solamente con una pequeña explicacion que le des.

Claro que existen diagramas UML pre-codificación y es como dijo @OscarRyz el Caso de Usos que como dice en el link de UML que te pasé es un Diagrama de Comportamiento, esa es su naturaleza por lo tanto tú debes tener claro cómo se va a comportar tu sistema antes de codificarlo no es así? Este diagrama es muy útil para describir a grandes rasgos lo que tu sistema va a hacer y cómo el usuaria va a intervenir con el.
En el libro de UML y Patrones que te recomendé explican muy bien la importancia de un caso de uso, no por que sea el más importante ni el que siempre debe ir, pero sí explica el porque y en donde usarlo, si le das una leída a ese libro te darás cuenta de esto. Suerte!

El de Craig Larman es muy bueno y ayuda muchísimo para tener un buen "feeling" de UML y un método iterativo de desarrollo.

Lo único malo es que es demasiado grande ( para mí lo fue al menos ) y me resultaba un tanto difícil de seguir, me pareció aburridón, así que me salto generalmente a las imagenes nada más.

Un excelente libro para también entender UP y UML es el libro "UML and the Unified Process" aunque ya esta medio viejito también ayuda muchísimo a entender por ejemplo la diferencia entre un diagrama de clase en análisis y uno en diseño.

Les dejo una imagen donde aparecen ambos por si a alguien le intersa:

"Basta comparar el ancho de el libro 'Design Pattern" y el de Larman"

Me costo mucho trabajo entender el libro de Craig Larman, tuve que dejarlo de estudiar 2 o 3 veces porque de plano me confundia, y despues de un tiempo volvia a estudiarlo, me ayudo mucho para entender el metodo iterativo y los patrones GRASP. Creo que los patrones GRASP son muy importantes para hacer una arquitectura como debe de ser.

muchas gracias por los comentarios ya le ando dando una leida a los libros.. y en breve empezare a darle a todo esto-.. creoq ya tengo bastante idea con lo que me respondieron..
igual si con el tiempo me surge algun problema/duda hay se las pongo
muchas gracias salu2