ulm y clases ¿para qué?

[black_flowers]

estoy bastante confundido con esto del uml y del diseño orientado a objetos. Un ejemplo: Hace poco hice un pequeño proyecto (en realidad no era nada profesional sino que lo hice por pasar el tiempo). consitia en un entorno de gestión de una ferretería en donde en el interfaz gráfico había un treeview con todas las categorías de los productos que hay en el almacén (que están en una base de datos) y cada vez que se selecciona una categoría en el treeview se visualizan todos esos productos en un datagridview. Vamos que es algo bastante típico. Lo que se puede hacer en el entorno es comprar productos para meter en el almacén y vender productos a los clientes. Lo típico un treeview una base de datos un datagrid y dos acciones: vender comprar. El programa es sencillo ya está hecho y como os podreis imaginar no hice ni una sóla clase ya que se basa sobretodo en la base de datos. Entonces: para estos pequeños proyectos ¿tiene algún sentido hacer clases y hacer esquemas uml? En caso de que sí... ¿qué clases se podrían crear?


perdonad por el rollo pero es que llevo mirando por internet, manuales ejemplos y demás y en teoría ya se hacer los esquemas uml y crear las clases el problema es que no le veo ninguna aplicación práctica.

1 saludo.

[franko1809]

Las clases te ayudan a encapsular codigo y en tu form solo mostrar
Instanciar_clase
nombre_De_clase(parametros)
Todo el codigo esta escondido por asi decirlo y asi poder usar esa clase en 10 formularios distintos con esas 2 lineas en lugar de poner todo el codigo para cada form y si se necesita modificar algo solo modificas la clase y no buscar en los 10 formularios y modificar uno a uno esto es a nivel de progrmacion al menos esa idea es la que tengo espero estar un 50% en lo correcto
En cuanto a uml y diagrama de clases que creo es lo que preguntas espero alguien responda

saludos

[black_flowers]

pues me vienes a decir lo que se dice en todos los manuales y en todo lo que llevo visto y encontrado en internet. Mi conclusión es que tienes razón y que es así pero la verdad yo no lo entiendo. Te especifico más en qué consiste la aplicación que pongo de ejemplo:

un treeview. Pulso en una categoría y el datagridview está conectado automáticamente con la base de datos de forma que selecciona todos los artículos de la categoría del treeview.

luego hay dos pestañas (comprar y vender). si le doy a comprar selecciono en el treeview la categoría, en el datagridview el producto y introduzco el número de unidades compradas y "compro"

para vender exactamente lo mismo.

la aplicación lo único que hace es modificar y visualizar lo que hay en la base de datos. Siempre hay ciertas acciones pero en general este tipo de aplicaciones se basan en gestionar la base de datos y son las típicas aplicaciones que se hacen para los negocios. Entonces, ¿sois capaces de ver alguna clase en esta aplicación? Es que yo simplemente no soy capaz de crear ninguna.

Si me baso en los manuales que he leído, existiría una clase "usuario", y una clase "almacén", de forma que un usuario puede hacer compras y ventas sobre el almacén. Pero en la realidad el almacén es la base de datos y el usuario pues simplemente es el que hace las acciones en el programa. La verdad no le acabo de ver la aplicación práctica.

un saludo.

[venkman]

En gran medida, realizar diagramas con UML es básicamente una operación de documentación.

Si tú haces un proyecto pequeño, que sólo haces tú, que nadie más va a modificar nunca, quizá no le veas sentido. Pero en cuanto tengas un proyecto en el que colaboren varias personas o se quiera mantener a lo largo del tiempo, ir modificando y añadiendo, o que simplemente necesites presentar a otra gente, necesitas tener algún tipo de estructuración y de documentación.

Una de las formas de hacer eso (hay otras muchas), es utilizar UML.

Si además tienes un proyecto en el que intervienen varias personas y unos se encargan del análisis, otros del diseño y arquitectura, otros de la implementación, etc. entonces UML es una buena forma de comunicar las diferentes partes del proyecto en un lenguaje estándar y claro para todos.



En el caso concreto de tu aplicación, todo se puede hacer de muchas formas. Partir de un diseño orientado a objetos (o más en general, un diseño modular) te da más flexibilidad cuando, en el futuro, tengas que añadir nuevas capacidades a tu programa. ¿Y si mañana resulta que quieres poder importar datos de productos desde un fichero externo a la base de datos? ¿Y si pudieras consultar catálogos de los proveedores y hacer el pedido y que automáticamente se actualizaran los stocks en el almacén cuandos e hace la entrega? ¿Y si desde el programa se quiere poder añadir nuevas categorías? No sé, mil cosas que quizá hoy no habías pensado, pero que poco a poco van añadiendo complejidad al proyecto.

En esos casos, si no has partido de un diseño ordenado, luego vas a ir añadiendo pegotes encima y al final, al cabo de los meses, terminarás teniendo un código bastante confuso. Sin embargo si partes de un diseño ordenado, y cuando quieres hacer un cambio lo insertas primero en el diseño para que encaje correctamente, entonces es más probable que el código se mantenga más o menos comprensible. Si luego estás sin tocar la aplicación durante 1 año y al cabo de ese tiempo quieres añadirle algo, entonces más te vale que esté bien organizado y bien documentado.


Ahora mismo puede que sólo tengas "un usuario" y un "almacén" (aunque, así de entrada yo también veo: producto, pedido, stock, factura...), pero quizá más adelante podrías tener diversos tipos de usuarios (cajero, supervisor, jefe) cada uno con diferentes permisos y operaciones, o varios almacenes diferentes, o catálogos de productos o... quién sabe qué.

[black_flowers]

sí, la verdad es que estoy intentando "ver" las clases que podría poner a ver si consigo hacer alguna.

1 saludo.

[apuyinc]

Para darte otro ejemplo del por qué usar clases:

- Qué pasaría si te piden cambiar el form y en lugar de un treeview te piden que uses un grid? O aún mejor, qué pasaría si te piden hacerlo en web?
Si tuvieras las clases que abastraen la funcionalidad de obtener datos - por ejemplo - tan solo tendrías que cambiar la interfaz y listo.

Saludos

[Javin1]

apuyink hay veces que UML no es lo mas "practico" a nivel de un software sencillo, consume mas tiempo a corto plazo, que de alguna manera es lo que muchas veces los clientes te "obligan" a cumplir a rajatabla. Lo mismo pasa en el desarrollo web, no seimpre es mejor usar, por ejemplo, el desarrollo de un web con un patron MVC.

salu2!