En los capítulos anteriores, aprendimos sobre las
estructuras básicas de los programas de orientación a objetos en .NET,
incluyendo campos, propiedades, métodos, constructores, eventos y herencia.
Ahora tenemos una base sólida para el diseño de proyectos orientados a objetos.
Es hora de usar este conocimiento para pensar
cómo desarrollar las clases que se han creado en el Visual Studio. NET.
Deseamos crear objetos que sean fáciles de usar para ello podemos usar
componentes.
Componente. Una parte reemplazable, casi independiente y no trivial de
un sistema que cumple una función clara en el contexto de una arquitectura bien
definida.
Aquí hay información adicional sobre componentes:
Manual Desarrollo de software basado en tecnologías orientadas a componentes. Formación para el Empleo (Fpe Formacion Empleo (cep))
Antes de ponernos a
crear una nueva librería de clases hay que hacerse estas preguntas:
¿Es posible disponer
de componentes comerciales ya desarrollados (CYD) para implementar el
requisito?
¿Se dispone de
componentes reutilizables desarrollados internamente para implementar el
requisito?
¿Son compatibles las
interfaces de los componentes que están disponibles dentro de la arquitectura
del sistema a construir?
Si la respuesta a
estas preguntas es no, entonces tendremos que crear una nueva biblioteca de
clases, si la respuesta es sí, entonces utilizaremos una biblioteca previamente
creada.
Para crear una
biblioteca de clases, compilada como .dll se crea un proyecto nuevo como
biblioteca de clases, (Class Library) o como biblioteca de controles (Windows
Control Library).
En nuestro caso elegimos Class Library.
Una Empresa Genérica
En
este documento trataremos de integrar todo lo aprendido hasta ahora, para ello
vamos a hacer un pequeño programa completo que gestione una empresa genérica
con el fin de poder reutilizar la estructura para desarrollos posteriores más
complejos.
Gestión de un Gran Almacén
Enunciado de los requisitos.
Se desea realizar la gestión
de un negocio de distribución de productos de alimentación.
Para ello se pide:
Gestión clientes
Los clientes pueden ser
personas jurídicas o físicas. Los datos que interesa mantener de los clientes
son un código único de cliente, nombre, razón social, dirección, lista de
teléfonos de contacto, ciudad, código postal, CIF/NIF, la forma de pago (que
puede ser contado o crédito; si fuera crédito puede hacerlo por domiciliación
bancaria, enviando talón o por cobrador),
Los clientes pueden darse de
alta, modificarse y darse de baja. Dar de baja a un cliente supone desactivarlo
no eliminarlo de la base de datos.
Gestión de proveedores
De los proveedores interesa
mantener los siguientes datos: un código único, nombre, razón social,
dirección, ciudad, código postal, lista teléfonos, fax,CIF/NIF. Los proveedores
pueden darse de alta, modificarse y darse de baja. Dar de baja un proveedor
supone desactivarlo a él y a los productos que sirve.
Gestión de artículos
Los artículos se dividen en familias. Cada
familia se caracteriza por un código y una descripción. Cada artículo se
compone de un código, nombre, IVA que se le aplica, precio de coste, precio de
venta, número de unidades. Cada artículo lo sirve un único proveedor.
Los artículos pueden darse de
alta, modificarse y darse de baja. Dar de baja un artículo supone desactivarlo
no eliminarlo de la base de datos.
Gestión de albaranes
Un albarán es un documento que
recoge los datos de una venta a un cliente.
Un albarán estaría formado por
una cabecera, por unas líneas de albarán y por un pie con los totales. La
cabecera tiene el número de albarán, los datos del cliente que se estimen oportunos
y la fecha de creación del albarán. Cada línea del albarán consta del código y
la descripción del artículo, el número de unidades, el precio de venta (que
puede diferir del precio de venta recogido en la definición del artículo), el
número de unidades bonificadas (las unidades bonificadas son unidades del
producto que se le entregan al cliente a mayores de las compradas a coste cero)
y el importe total del artículo.
El pie recoge los totales de
la siguiente forma: existirá una fila por cada base de IVA diferente aplicado
en los diferentes artículos. Cada fila tendrá cuatro columnas, la primera
indica la base de IVA aplicado, la segunda la suma de los importes de los artículos
a los que aplicarles ese IVA, la tercera el IVA, la cuarta sería la suma de los
importes con el IVA aplicado. Por último, aparecerá el total a pagar.
De un albarán debe saberse si
está pagado o no.
Los albaranes pueden crearse
en cualquier momento. Un albarán puede borrarse sólo si no existe una factura
asociada. Un albarán puede modificarse siempre, pero teniendo en cuenta que si
se modifica un albarán que tiene asociada una factura, ésta se verá modificada
a su vez.
Gestión de facturas
Una factura recoge la
información de un conjunto de albaranes pertenecientes a un cliente. Una
factura consta de una cabecera, un cuerpo de factura y un pie de factura. La
cabecera de la factura tiene los siguientes datos: datos fiscales del emisor de
la factura, datos fiscales del cliente (CIF/NIF, razón social, nombre...),
fecha y número de factura (el número de factura es único y asignado por el
sistema, iniciándose cada mes de Enero).
El cuerpo de la factura
estaría formado por los albaranes que forman la factura, de manera que para
cada uno de ellos aparezca el número del albarán y las líneas del albarán. El
pie de factura sería similar al pie de albarán, pero haciendo referencia a todos
los albaranes que se contemplan en dicha factura.
El proceso de facturación se
lleva a cabo dando el rango de clientes a los que se quiere facturar y un rango
de fechas para seleccionar los albaranes. Las facturas sólo pueden crearse. Si
hace falta modificar su contenido se modifican los albaranes correspondientes.
Las facturas no pueden borrarse.
Diseño del diagrama de clases
Clase CCliente: Clase que representa la información de personas que son clientes
del almacén identificadas unívocamente por codigo_cliente. Se relaciona con la
clase CAlbaran a través de la asociación
pertenece, pudiendo tener varios albaranes, y con la clase CTelefono a través de la asociación tiene.
Clase
CAlbaran: Clase que recoge los datos de
una venta a un cliente. Un albarán es un documento que está formado por líneas
donde cada una se corresponde con un artículo (ver siguiente Clase). Se
relaciona con la clase CCliente mediante la asociación
pertenece y con CFactura mediante la asociación
recoge_info_de.
CLínea: recoge toda la información acerca del
pedido de un artículo a un cliente dentro de un albarán. Una o más líneas
forman parte de un albarán. A través de la asociación consta_de se relaciona
con la clase CArtículo.
Clase CFactura: Clase
que contiene los datos acerca de un conjunto de albaranes y los datos del
cliente al cual pertenece dicha factura. Se relaciona con la clase CAlbaran
mediante la asociación recoge_info_de. Una factura se compone de cabecera,
cuerpo y pie, esta información se recoge dentro de la misma clase CFactura.
Clase
CArtículo: Almacena
los datos sobre los productos servidos por los proveedores. Cada artículo es
parte de una familia y es servido por un solo proveedor. A través de la
asociación consta_de se relaciona con la clase CLínea del
albarán.
Clase CFamilia: Clase que representa la
abstracción de un conjunto de artículos con características similares.
Clase CProveedor: Clase que representa la información de personas. Se
relaciona con la clase CArtículo a través de la asociación provee
y con la clase CTelefono a través de la asociación
tiene.
Pr
CTelefono: en este caso se mantendrá una
lista de teléfonos correspondientes a los clientes y a los proveedores, que se referenciarán
por las clases correspondientes a través de los roles teléfono_cliente y
teléfono_proveedor .
Aspectos más interesantes del diseño del diagrama
El enumerador <<Enum>>
FormaDePago, es un tipo de dato que hemos
creado especialmente para este diagrama. Los posibles valores que puede tener
son: contado, credito_domiciliacion_bancaria, credito_cobrador y credito_talon.
La clase CFactura deberá tener un atributo que
sea forma_de_pago del tipo FormaDePago que especifique cómo se va a pagar
dicha factura. En cliente tendremos un método pagar donde pagaremos la factura
asociada a dicho cliente y al que le pasaremos el tipo de dato FormaDePago. Como se puede observar en el diagrama,
usamos agregación entre Albarán y Línea; y entre Familia y Artículo. En lugar
de tener dos clases para los teléfonos de cliente y proveedor respectivamente,
agrupamos todos los teléfonos en una única clase los cuales se distinguirán por
el rol que utilizan las clases cliente y proveedor.
Como el Cliente y el Proveedor son casi idénticos podemos
hacer lo siguiente:
Aquí el esquema completo de la
empresa genérica.
Relaciones
Estas son las relaciones entre las diferentes
clases:
-Relación de tipo Agregación entre clase CLinea y
clase CAlbaran
un albarán está compuesto por
una o varias líneas.Éstas a su vez sólo pueden pertenecer a un albarán.
Cardinalidad
origen: 1..n
Cardinalidad
destino: 1
- Relación de tipo Asociación entre clase CLinea y
clase CArticulo
Nombre
de la relación: consta_de
Descripción:
en una
línea se recoge la información de un solo artículo. Un mismo tipo de artículo
puede aparecer en varias líneas.
Cardinalidad
origen: 0..n
Cardinalidad
destino: 1
- Relación de tipo Agregación entre clase CArticulo y
clase CFamilia
Descripción:
los
artículos están divididos en familias. Un artículo sólo puede pertenecer a una
familia.
Cardinalidad
origen: 0..n
Cardinalidad
destino: 1
- Relación de tipo Asociación entre clase CProveedor y
clase CArticulo
Nombre
de la relación: provee
Descripción:
un
artículo es servido por un único proveedor, pero un proveedor puede servir
varios artículos.
Cardinalidad
origen: 1
Cardinalidad
destino: 1..n
- Relación de tipo Asociación entre clase CProveedor y
clase CTelefono
Nombre
de la relación: tiene
Descripción:
un
proveedor tiene una lista de teléfonos de contacto.
Cardinalidad
origen: 0..n
Cardinalidad
destino: 0..n
- Relación de tipo Asociación entre clase CCliente y
clase CTelefono
Nombre
de la relación: tiene
Descripción:
un
cliente puede tener varios teléfonos de contacto.
Cardinalidad
origen: 0..n
Cardinalidad
destino: 0..n
- Relación de tipo Asociación entre clase CAlbaran y
clase CCliente
Nombre
de la relación: pertenece
Descripción:
un
albarán recoge la información de un solo cliente y un mismo cliente puede tener
asignado varios albaranes.
Cardinalidad
origen: 0..n
Cardinalidad
destino: 1
- Relación de tipo Asociación entre clase CFactura y
clase CAlbaran
Nombre
de la relación: recoge_info_de
Descripción:
una
factura recoge la información de uno o varios albaranes pero un albarán puede
aparecer en una factura o no (si no se ha facturado).
Cardinalidad
origen: 0..1
Cardinalidad
destino: 1..n
Como Se Puede Realizar Este Programa Con Otros Diagramas UML
ResponderEliminarLo siento, no soy experto en UML
ResponderEliminar