Modelado de Software

que tal quisiera ver si alguien puede orientarme sobre modelado de software

el caso es que me dejaron para un proyecto de mi escuela diseñar un software que calcule las intensidades de que arroja diversas lamparas con leds.. etc, bueno el punto es que aparte de que voy a programar tengo que entregar documentacion y el diseño del programa entes de hacerlo.

ahora mi duda es, como modelo el programa? buscando por ahi vi que puedo hacer:

diagrama de bloques
diagrama de flujo de datos
diagramas de flujo
entre otros

la cuestión es que utilizo para cada cosa.. tengo que entregar la documentacion para el usuario final, los "clientes" que me piden el programa y la documentacion para los futuros desarrolladores cuando yo no este.

buscando mas información tengo algunas ideas para hacer:

Diagrama a bloques o diagrama de flujo de datos.. para presentar el software sobre como sera y como funcionara antes de programar.
diagrama UML para la documentacion para los programadores para que sepan como funciona internamente el programa
diagrama de flujo para ciertas funciones internas que se creen y que se tenga que explicar para un futuro programador

bueno son algunas de mis ideas, ahora si alguien tiene una mejor opcion o si hay patrones estandares para ello que me diga cuales, y si me pueden pasar links donde encuentre ejemplos para cada cosa no es que sea flojo pero no encuentro.
o algun libro que me recomienden sobre modelado de software o no se...

salu2 se los agradeceria

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de beto.bateria

Que tal: Si programas

Que tal:

Si programas orientado a objetos, Argouml te puede ayudar, lo puedes bajar de aqui http://argouml.tigris.org/

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.

Imagen de Marce

IS

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

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:

http://download.oracle.com/javase/7/docs/

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.

Imagen de beto.bateria

El libro Uml y patrones de

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.

Imagen de genitalico

gracias

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 .

Imagen de beto.bateria

Creo que el mockup es para

Creo que el mockup es para mostrar el funcionamiento, encontre esto http://balsamiq.com/products/mockups, 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.

Imagen de Marce

UML

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

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"

Imagen de beto.bateria

Me costo mucho trabajo

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.

Imagen de genitalico

muchas gracias por los

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