Proyecto

Universidad de Panamá Centro Regional Universitario de Veraguas Facultad de Informática, Electrónica y Comunicaciones Carrera: Licenciatura en Informática Educativa y Empresarial

Trabajo de programación IV Tema PROYECTO #1 Profesor: Diego Santimateo G.

Integrantes: Enocjahaziel Carrasco José García Carlos Álvarez H Herman Franco

9-726-1139 9-728-1643 9-718-2419 9-721-2310

Fecha: Septiembre 26 de 2008

Índice

Introducción…………………………………………….……….……...3 Objetivos…………………………………………………………….… 4 Organización de los datos recabados…………………….…….…...5 Entrevista……………………………………………………….……….6 Utilidad de la información……………………………………………..9 Análisis Orientado a Objetos……………………………………..….10 Descripción del problema……………………………………………..11 Análisis Orientado a Objetos aplicando a Modelo según Miguel Avian …………………………………………12 Glosario…………………………………………………………….…..12 Identificación de las clases del dominio…………………………..14 Descripción del funcionamiento de cada clase………..…………..15 Descripción de la clases del dominio……………………………….16 Relaciones entre las clases ………………………………………….16 Diagrama de relación ……………………………….………………..17 Identificación de los atributos……………………..………………….17 Diagrama UML…………………………………………………………17 Diagrama de clase de uso ……………………………………………18 Síntesis………………………………………………………………….19 Reflexiones……………………………………………………………..35 Conclusión……………………………..……………………………….40

2

INTRODUCCIÓN. La base de toda empresa comercial es la compra y venta de bienes o servicios de aquí la importancia del manejo del inventario de la misma. Este manejo contable permitirá a la empresa mantener el control financiero, así como también conocer al final del periodo contable un estado confiable de la situación económica de la empresa. Básicamente, los resultados obtenidos durante el análisis orientado a objetos sirven como modelo o punto de partida para realizar el diseño del sistema, entonces podremos contar con creaciones más eficientes, que acentúen su funcionalidad y minimicen el problema. Presentamos una propuesta UML de un modelo Orientado a Objetos, en un Sistema de Inventario de una empresa. Para el desarrollo de esta propuesta hemos realizado cada una de las etapas que involucra la parte de análisis Orientada a Objetos y la documentación UML. Mostraremos el modelo de una entrevista utilizada para conocer el funcionamiento, documentos e informes utilizados en el sistema de administración de inventario. Se presentara un diagrama de relación de la clase y el diagrama de caso de usos enfocados al inventario de la empresa.

3

Objetivos - Objetivo General del proyecto •Desarrollar un modelo UML de información O.O., basado en el enfoque de la fase de análisis de sistema de inventario centrado en los componentes, transacciones, usuarios, características, relaciones y requerimientos. -Objetivos Específicos •Explorar y analizar información sobre la fase de análisis de sistemas. •Organizar entrevistas para conocer especialistas que proporcionen información sobre el dominio donde se desarrollará el Sistema. •Desarrollar el análisis y diseño OO basados en las distintas etapas que le conforman. •Diseñar modelos UML del dominio del problema basado en la metodología de desarrollo de sistemas (POO).

4

2. ORGANIZACIÓN DE LOS DATOS RECABADOS DE LA ENTREVISTA

Como parte de la primera etapa (análisis OO), hemos organizado una entrevista con el objetivo de conocer

documentos e informes utilizados en un sistema de

administración de inventario. La entrevista fue realizada a la empresa Junior Internet ubicada en calle 8va, donde se consulto con la persona encargada de llevar el control administrativo, en este caso con el dueño de la empresa el Sr. Jorge Luis Espinosa. A continuación presentamos un informe de los datos recabados y de la información generada, con el fin de desarrollar una propuesta UML de un Modelo Orientado a Objeto como parte de la fase de análisis que se pretende realizar.

5

Entrevista OBJETIVO: Hacer una propuesta UML de un modelo Orientado a Objetos, de un sistema de inventario centrado en los componentes, transacciones, usuarios,

características,

relaciones y requerimientos. INDICACIONES: Sea honesto y preciso y marque la respuesta que exprese mejor su opinión. 1¿Qué tipo de actividad tiene esta empresa? R/. x Giro Comercial.

Giro Industrial.

Giro de Servicios.

2¿Como ubica el tamaño de esta empresa? R/. x Micro

Pequeña

Mediana

Grande

3¿Qué tipo de inventario utiliza en esta empresa? R/. x Inventario de mercancía x Inventario de productos terminados Inventario de productos en proceso de fabricación Inventario de materias primas Inventario de suministros de fábrica 4¿Qué papel desempeña usted en esta empresa? R/. Dueño de la empresa y administrador. 5¿Qué sistema de tiempo utiliza para realizar el inventario? R/. X

El sistema de inventario periódico El sistema de inventario perpetuo

6¿Que tipo de costeo utiliza la empresa? R/. x

Costo unitario especifico 6

Costo promedio ponderado Costo de primeras entradas, primeras salidas (PEPS). Costo de últimas entradas, primeras salidas (UEPS). 7¿Cómo se realiza el inventario de la empresa? R/. x

Sistematizado Manual

8¿ Qué tipo de documentos utiliza para llevar el control de entradas? R/. x

Hoja de datos Un tarjetario por producto Formularios de despacho Hoja de diario (resumen del inventario mensual)

9¿Qué tipo de documentos utiliza para llevar el control en el inventario de las salidas? R/. Se utiliza como documentos las hoja de Datos y Tarjetarios 10¿Se hace algún informe sobre los costos incurridos para determinar las ganancias o las pérdidas? R/. Si, se hace un informe al final del mes para comparar los costos. 11.¿Como clasifica usted las compras de sus productos? R/. Por departamentos: •

Reparaciones y mantenimientos

•

Papelería

•

Refresquería

12.¿Cree usted que con un sistema de inventario sistematizado se facilitaría el trabajo? R/. Si , ya que se reduciría el tiempo, gastos, además las cuantas estarían mas seguras y menos porcentaje de un error humano(errores en las cuantas por una mal suma o resta ). 7

13¿Cómo le gustaría que se dieran los informes finales del inventario ? R/. Diarios, mensuales, Ganancias, Gastos por departamentos de una forma grafica.

8

Utilidad de la información La información obtenida hasta el momento nos servirá como base para el diseño de un modelo conceptual que represente los conceptos más importantes del dominio para el que se desarrolla la propuesta UML. Nos guiaremos en base a los resultados

obtenidos para

realizar un análisis

detallado de un sistema de inventario y elaborar los diagramas UML que la primera etapa de análisis OO requiere. Como parte de las siguientes etapas que se desarrollaran, utilizaremos los resultados de ésta técnica de entrevista, para conocer requerimiento de información que ayuden a detectar requisitos necesarios que el sistema debe cumplir.

9

10

DESCRIPCIÓN DEL PROBLEMA O DOMINIO En Júnior Internet se necesita un Sistema sistematizado, que lleve el control de inventario, y que además permita identificar las áreas de deficiencia, estadísticas de gastos por departamentos y control de artículos del local. Definición del dominio El dominio Seria Júnior Internet , ya que esta no cuenta con un sistema de inventario sistematizado ya que se hace manual. OBJETIVOS DEL SISTEMA Diseñar un sistema Sistematizado para lograr un mejor control de las entradas y salidas en el inventario y dar como resultado el costo de los artículos del local

Planeamientos de la entrevista 1- Se Organizo el Grupo para generar las preguntas a la empresa. 2- Se escogió la empresa a la cual se iba a presentar la entrevista. 3- Se consulto en la empresa sobre quien es la persona encargada de llevar el control administrativo. 4- Se planeo una cita con la persona que lleva el control administrativo., 5- Se llevo acabo la entrevista el día acordado con la persona encargada de Júnior Internet y se obtuvieron los resultados.

11

ANALISIS ORIENTADO A OBJETOS APLICANDO EL MODELO SEGÚN MIGUEL AVIAN GLOSARIO Compra: Es la adquisición de un activo fijo por el cual se origina una obligación de pago. Las compras de activos fijos se efectúan utilizando el procedimiento establecido con la referente a las Solicitudes de Autorización de Inversiones. Compras: El costo de las mercancías que compra una empresa para revenderlas a los clientes en el curso normal de los negocios. Costo: Es la magnitud de los recursos, materiales laborales y monetarios necesarios para alcanzar un cierto volumen de producción con una determinada calidad. Costo promedio ponderado: método de valuación para el inventario, el costo promedio ponderado, se calcula dividiendo el costo total de la mercancía disponible para la venta entre

el

número

de

unidades

disponibles

para

la

venta.

Costo unitario: Puede medirse en función de su producción y distribución. Este costo es el que sirve para valuar las existencias que aparecen en el balance general y estado de pérdidas y ganancias en los renglones de los inventarios de producción en proceso y productos terminados. También puede medirse en relación con la posibilidad de aplicar directa

o

indirectamente

a

la

unidad

los

gastos

incurridos.

Cuentas: El registro detallado de los cambios que han ocurrido en un activo, un pasivo o en la participación en el capital del propietario en particular durante un período. Un registro utilizado para resumir todos los aumentos y disminuciones en un activo determinado, como por ejemplo efectivo, inventarios o cualquier otro tipo de activo, pasivo o

patrimonio,

ingreso

o

gasto.

Hoja de datos: Un documento estructurado en columnas creado para ayudar la transferencia de información de los estados financieros. Es una hoja de columnas diseñada para colocar en forma conveniente todos los datos contables que se necesitan al

final

del

período.

Informe: Exposición, generalmente escrita, sobre un asunto o persona, en el que se aportan datos y valoraciones para que sea fácil tomar una decisión al respecto. El resultado de cualquier acción de control. Inventario: Los inventarios son bienes constituidos por adquisición, en proceso de elaboración o terminados, bien sean para consumo o para su comercialización. Inventario perpetuo o continuo: También conocido como sistema de pedido de intervalo variable. Sistema de control de inventario y reabastecimiento en el cual los niveles de 12

existencias son revisados constantemente y los pedidos se hacen cuando la existencia baja o supera un nivel predeterminado. En este sistema los reabastecimientos se hacen generalmente por cantidades estándares pero no se llevan a cabo en fechas establecidas de antemano. Inventario periódico: También conocido como sistema de pedidos de intervalos fijos Sistema de control de inventarios y reabastecimientos en el cual se revisan los niveles de existencias a intervalos de tiempo predeterminados y los pedidos se basan en los niveles actuales de existencias, el nivel de reserva de emergencia y un máximo establecido. Mediante este método el reabastecimiento se hace sobre una base preestablecida, es decir, en una fecha fija. Sin embargo, la cantidad del pedido puede variar en cada ocasión. Producto: valor recibido de la venta de un documento por cobrar antes de la fecha de vencimiento. El valor al vencimiento menos el descuento es igual al producto. Tarjetario: Tarjeta donde se escribe el control de entrada y salida de los artículos adquiridos o vendidos por la empresa. Es usada cuando la empresa utiliza un sistema de inventario manual. Venta: Constituye la entrega de un activo fijo a otra entidad creando un derecho de cobro y por ende cambio de propiedad. En tales casos el modelo de Movimiento debe estar soportado por la factura correspondiente, con la debida autorización del funcionario facultado para ello en el nivel superior que corresponda, donde se especifiquen las condiciones y forma de pago.

13

Identificación de las clases del dominio Extraeremos las clases de la descripción del problema y de las entrevistas realizadas a especialistas en el dominio. Clases del Dominio “Inventario” Class Articulo ; Nombre; ; Código; ; Cantidad; ; Precio Unitario; ; DescripArt; ; PrecioTotal ( ) ;

Class Proveedor ; Nombre; ; Código; ; Articulo; ; Precio Unitario; ; DescripArt; ; TotalMerc ( );

Class Compras ; Proveedor; ; Precio de la compra; ; Cantidad; ; Precio Unitario; ; Orden de Compra; ; TotalCompra( );

Class Ventas ; Clientes; ; Precio de la Venta; ; Cantidad; ; Precio Unitario; ; Nº de Factura; ; TotalVenta( );

Class Funciones ; Captura ( ); ; Despliega ( ); ; suma ( );

14

Descripción Breve el funcionamiento de las clases Utilizadas en el Sistema de Inventario.

Clases Class Articulo

Class Compras

Class Venta

Class Proveedor

Descripción del Funcionamiento de cada Clase Atributos Métodos Funcionalidad del método: nombre: nombre del articulo PrecioTotal();: precio total de código: dígitos que identifica a un articulo. cantidad: cantidad de articulo. un Articulo. Precio unitario: Costo de un articulo descripArt:. Descripción del articulo. Proveedor: Distribuidor del la TotalCompras ( );:Cuanto es mercancía. el valor total de la compra. precio de la compra: Costo de la ; CantArt( );: Cantidad de mercancía Articulos Comprados. Cantidad: .Cantidad de mercancía comprada Precio Unitario: Costo de un articulo. Orden de Compra: numero de orden de compra. TotalVenta( );: Cuanto es el Clientes: Usuario valor total de la venta. Precio de la Venta: Costo del mercancía. Cantidad: Cantidad de artículos vendidos. Precio Unitario: Costo de un Articulo. Nº de Factura: Numero de factura. Nombre: nombre del Proveedor TotalMerc( );:Cuanto asiende Código: dígitos que identifica a al el total de compra al provedor. Proveedor del Articulo. Articulo: Articulo que Distribuye el proveedor. Precio Unitario: Costo de un articulo por unidad DescripArt:. Descripción del articulo.

Descripción de las clases del dominio: Descripción de las clases abstraídas que forman parte del sistema Inventario.

15

Clases

Atributos

Funcionalidad de los métodos : captura( ):captura los datos o mensajes necesarios para el funcionamiento del sistema. despliega( ): despliega los datos, mensajes necesarios. suma(): realiza la suma de diferentes cantidades.

--------------

Class Funciones

Relaciones entre las Clases: •

Articulo tiene Ventas.

•

Articulo tiene Proveedor.

•

Compras se hacen a un proveedor.

•

Ventas tiene Descripción de Articulo.

•

Proveedores venden Artículos.

•

Compra Necesita de Artículos.

Diagrama de relación de las clases.

Class Proveedor

Tienen Venden

Class Art 兤 ulo

Class Venta Tienen

Descripci

Se hacen a

de

Class Compra Necesita 16

Identificación de los atributos y propiedades de las clases

En esta etapa se identifican los atributos y propiedades que tendrán las clases, como sabemos los atributos o características de una Clase pueden ser de tres tipos, mediante A continuación presentamos el Diagrama de clases para una mejor organización jerárquica de las clases. El mismo identifica atributos, tipo de variables, (primitivas o de la clase String), y métodos que le permitirán interactuar y realizar diferentes operaciones. Diagrama UML (Organización de las clases- incluye: Nombre de la clase, atributos y métodos)

Class Funciones; Captura ( ); ; Despliega ( ); ; suma ( );

Class Articulo; Nombre; ; Código; ; Cantidad; ; Precio Unitario; ; DescripArt;; PrecioTotal ( ) ;

Inventario Sistema de inventarioMain

Class Ventas; Clientes; ; Precio de la Venta; ; Cantidad; ; Precio Unitario; ; Nº de Factura;; TotalVenta( );

Class Compras; Proveedor; ; Precio de la compra; ; Cantidad; ; Precio Unitario; ; Orden de Compra; ; TotalCompra( ); ; CantArt( );

Class Proveedor; Nombre; ; Código; ; Articulo; ; Precio Unitario; ; DescripArt;; TotalMerc ( );

17

Diagrama de Caso de Uso: Caso de uso: administrador Verificando las el tarjetario con los artículos físicos

En el Departamento

Tarjetari o

compara

verifica

Pasa a inventario Físico Entrada

Tarjeta vs Inventario F.

Verifica

Refleja

Salidas

Margen de utilidad o perdida.

18

19

ENOCJAHAZIEL CARRASCO MODELAMIENTO DE LAS CLASES CLASES Unidad básica que encapsula toda la información de un Objeto. Se representa con un rectángulo con tres posiciones: en la parte superior contiene el nombre de la clase, en el intermedio atributos y la parte inferior los métodos. Nombres Atributos Métodos

Atributos Pueden ser de tres tipos • public : Indica que el atributo será visible tanto dentro como fuera de la clase. •

Private : sólo sus métodos lo pueden acceder.

•

protected : Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accedido por métodos de la clase además de las subclases que se deriven.

Métodos: • public (): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. •

private (): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden acceder).

•

protected (): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accedido por métodos de la clase además de métodos de las subclases que se deriven (ver herencia). RELACIONES

Forma en que se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes). Herencia Es una subclase de que hereda los métodos y atributos de una Súper Clase

20

Agregación

Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Asociación

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro. Dependencia

Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra

CASOS PARTICULARES

Clase Abstracta Una clase abstracta se denota con el nombre de la clase y de los métodos con letra "itálica". Esto indica que la clase definida no puede ser instanciada pues posee métodos abstractos Clase parametrizada Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los parámetros que deben ser pasados a la clase para que esta pueda ser instanciada

21

Diagrama de interacción El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en petición a un evento Los componentes de un diagrama de interacción son: • Un objeto o Actor • Mensaje de un objeto a otro objeto • Mensaje de un objeto a si mismo Elementos Objetos o Actor Rectángulo que representa una instancia de un Objeto

Mensaje a otro Objeto Se representa por una flecha entre un objeto y otro, representa la llamada de un método a otro de un objeto en particular.

Mensaje al mismo objeto No solo llamadas a métodos de objetos extremos pueden realizarse, también es posible visualizar llamadas desde el mismo objeto en estudio

22

Hernán Franco G. 1. Modelos Un modelo representa a un sistema software desde una perspectiva específica. Los modelos de UML que se tratan en esta parte son los siguientes: • Diagrama de Estructura Estática. • Diagrama de Casos de Uso. • Diagrama de Secuencia. • Diagrama de Colaboración. • Diagrama de Estados. 2. Elementos Comunes a Todos los Diagramas 2.1 Notas Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama. 2.2 Dependencias Una dependencia se representa por medio de una línea de trazo discontinuo entre los dos elementos con una flecha en su extremo. 3 Diagramas de Estructura Estática Los Diagramas de Estructura Estática de UML se van a utilizar para representar tanto Modelos Conceptuales, como Diagramas de Clases de Diseño 3.1 Clases Una clase se representa mediante una caja subdividida en tres partes: En la superior se muestra el nombre de la clase, en la media los atributos y en la inferior las operaciones. 3.2 Objetos Un objeto se representa de la misma forma que una clase. En el compartimiento superior aparecen el nombre del objeto junto con el nombre de la clase subrayados. 3.3 Asociaciones Las asociaciones entre dos clases se representan mediante una línea que las une. 3.3.1 Nombre de la Asociación y Dirección El nombre de la asociación es opcional y se muestra como un texto que está próximo a la línea. Los nombres de las asociaciones normalmente se incluyen en los modelos para aumentar la legibilidad. Sin embargo, en ocasiones pueden hacer demasiado abundante la información que se presenta, con el consiguiente riesgo de saturación. 3.3.2 Multiplicidad La multiplicidad es una restricción que se pone a una asociación, que limita el número de instancias de una clase que pueden tener esa asociación con una instancia de la otra clase. 3.3.3 Roles Para indicar el papel que juega una clase en una asociación se puede especificar un nombre de rol. 3.3.4 Agregación El símbolo de agregación es un diamante colocado en el extremo en el que está la clase que representa el “todo”. 3.3.5 Clases Asociación Cuando una asociación tiene propiedades propias se representa como una clase unida a la línea de la asociación por medio de una línea a trazos. 3.3.6 Asociaciones N-Arias En el caso de una asociación en la que participan más de dos clases, las clases se unen con una línea a un diamante central. 3.3.7 Navegabilidad "navegar" desde el objeto de la clase origen hasta el objeto de la clase destino. 3.4 Herencia La relación de herencia se representa mediante un triángulo en el extremo de la relación que corresponde a la clase más general o clase “padre”. 3.5 Elementos Derivados Un elemento derivado es aquel cuyo valor se puede calcular a partir de otros elementos presentes en el modelo, pero que se incluye en el modelo por motivos de claridad o como decisión de diseño. 4 Diagrama de Casos de Uso Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema.

23

Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. 4.1 Elementos Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso. 4.1.1 Actores Un actor es algo con comportamiento, como una persona (identificada por un rol). 4.1.2 Casos de Uso Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. 4.1.3 Relaciones entre Casos de Uso Un caso de uso, en principio, debería describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es útil describir una interacción con un alcance menor como caso de uso. La razón para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicación en el equipo de desarrollo, el manejo de la documentación de casos de uso. • Incluye (<>): Un caso de uso base incorpora explícitamente a otro caso de uso en un lugar especificado en dicho caso base. • Extiende (<>): Cuando un caso de uso base tiene ciertos puntos (puntos de extensión) en los cuales, dependiendo de ciertos criterios, se va a realizar una interacción adicional. 5 Diagramas de Interacción En los diagramas de interacción se muestra un patrón de interacción entre objetos. 5.1 Diagrama de Secuencia Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal de eventos. 5.2 Diagrama de Colaboración Un Diagrama de Colaboración muestra una interacción organizada basándose en los objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se refiere). En cuanto a la representación, un Diagrama de Colaboración muestra a una serie de objetos con los enlaces entre los mismos, y con los mensajes que se intercambian dichos objetos. 6 Diagramas de Estado Un Diagrama de Estados muestra la secuencia de estados por los que pasa bien un caso de uso, bien un objeto a lo largo de su vida, o bien todo el sistema. 7 Modelado Dinámico 7.1 Diagramas De Actividades Vamos a recordar los diferentes modelos que sirven para representar el aspecto dinámico de un sistema: • Diagramas de secuencia. • Diagramas de colaboración. • Diagramas de estados. • Diagramas de casos de uso. • Diagramas de actividades. En este capítulo nos centraremos en los diagramas de actividades que sirven fundamentalmente para modelar el flujo de control entre actividades. La idea es generar una especie de diagrama Pert. El diagrama de actividades sirve para representar el sistema desde otra perspectiva, y de este modo complementa a los anteriores diagramas vistos. 7.2 Contenido del diagrama de actividades Básicamente un diagrama de actividades contiene: • Estados de actividad. • Estados de acción. • Transiciones. • Objetos. 7.2.1 Estados de actividad y estados de acción La idea central es la siguiente: “Un estado que represente una acción es atómico, lo que significa que su ejecución se puede considerar instantánea y no puede ser interrumpida”. 7.2.2 Transiciones Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de acción.

24

7.2.3 Bifurcaciones Un flujo de control no tiene porqué ser siempre secuencial, puede presentar caminos alternativos. Para poder representar dichos caminos alternativos o bifurcación se utilizará como símbolo el rombo. Dicha bifurcación tendrá una transición de entrada y dos o más de salida. En cada transición de salida se colocará una expresión booleana que será evaluada una vez al llegar a la bifurcación. 7.2.4 División y unión UML representa gráficamente el proceso de división, que representa la concurrencia, y el momento de la unión de nuevo al flujo de control secuencial, por una línea horizontal ancha. 7.2.5 Calles Cuando se modelan flujos de trabajo de organizaciones, es especialmente útil dividir los estados de actividades en grupos, cada grupo tiene un nombre concreto y se denominan calles. 8. Modelado Físico De Un Sistema OO 8.1 Componentes Los componentes pertenecen al mundo físico, es decir, representan un bloque de construcción al modelar aspectos físicos de un sistema. Una característica básica de un componente es que: “debe definir una abstracción precisa con una interfaz bien definida, y permitiendo reemplazar fácilmente los componentes más viejos con otros más nuevos y compatibles.” 8.1.1 Interfaces La relación entre un componente y sus interfaces se puede representar de dos maneras diferentes, de forma icónica y de forma expandida 8.1.2 Tipos de componentes Existen básicamente tres tipos de componentes: ? Componentes de despliegue. ? Componentes producto del trabajo. ? Componentes de ejecución. 8.1.3 Organización de componentes Los componentes se pueden agrupar en paquetes de la misma forma que se organizan las clases. 8.1.4 Estereotipos de componentes UML define cinco estereotipos estándar que se aplican a los componentes: executable Componente que se puede ejecutar en un nodo. 8.2 Despliegue 8.2.1 Nodos Vamos a definir un nodo como un elemento físico, que existe en tiempo de ejecución y representa un recurso computacional que generalmente tiene alguna memoria y, a menudo, capacidad de procesamiento. Los nodos sirven para modelar la topología del hardware sobre el que se ejecuta el sistema. Un nodo debe tener un nombre asignado que lo distinga del resto de nodos. 8.2.2 Nodos y componentes En muchos aspectos los nodos y los componentes tienen características parecidas. PARECIDOS Ambos tienen nombre DIFERENCIAS Los Nodos Los Componentes Son los elementos donde se ejecutan los componentes. Existen dos tipos de diagramas que sirven para modelar los aspectos físicos de un sistema orientado a objetos: • Diagramas de Componentes • Diagramas de Despliegue 8.3 Diagramas de Componentes Un diagrama de componentes muestra la organización y las dependencias entre un conjunto de componentes. 8.3.1 Usos más comunes a) Modelado de Código Fuente. b) Modelado de una versión ejecutable y bibliotecas. c) Modelado de una base de datos física 8.4 Diagramas de Despliegue 8.4.1 Técnicas más comunes de modelado a) Modelado de un sistema empotrado El desarrollo de un sistema empotrado es más que el desarrollo de un sistema software. Hay que manejar el mundo físico. Los diagramas de despliegue son útiles para facilitar la

25

comunicación entre los ingenieros de hardware y los de software. b) Modelado de un sistema cliente servidor La división entre cliente y servidor en un sistema es complicada ya que implica tomar algunas decisiones sobre dónde colocar físicamente sus componentes software, qué cantidad de software debe residir en el cliente, etc. 8.5 Arquitectura del Sistema 8.5.1 Arquitectura de tres niveles La llamada “Arquitectura en Tres Niveles”, es la más común en sistemas de información que además de tener una interfaz de usuario contemplan la persistencia de los datos. Una descripción de los tres niveles sería la siguiente: Nivel 1: Presentación – ventanas, informes, etc. Nivel 2: Lógica de la Aplicación – tareas y reglas que gobiernan el proceso. Nivel 3: Almacenamiento – mecanismo de almacenamiento. 8.5.2 Arquitectura de tres niveles orientadas a objetos a) Descomposición del nivel de lógica de la aplicación En el diseño orientado a objetos, el nivel de lógica de la aplicación se descompone en sub-niveles que son los siguientes: Objetos del Dominio: son clases que representan objetos del dominio. Servicios: se hace referencia a funciones de interacción con la base de datos, informes, comunicaciones, seguridad, etc. 8.5.3 Arquitectura MULTI-nivel La arquitectura de tres niveles puede pasar a llamarse de Múltiples Niveles si tenemos en cuenta el hecho de que todos los niveles de la arquitectura de tres niveles se pueden descomponer cada uno de ellos cada vez más. 8.5.4 Paquetes La forma que tiene UML de agrupar elementos en subsistemas es a través del uso de Paquetes, pudiéndose anidar los paquetes formando jerarquías de paquetes. De hecho un sistema que no tenga necesidad de ser descompuesto en subsistemas se puede considerar como con un único paquete que lo abarca todo. 8.5.5 Identificación de Paquetes • Conviene agrupar elementos que proporcionen un mismo servicio. • Los elementos que se agrupen en un mismo paquete han de presentar un alto grado de cohesión, es decir deben estar muy relacionados. • Los elementos que estén en diferentes paquetes deben tener poca relación, es decir deben colaborar lo menos posible. 9 Proceso de Desarrollo Cuando se va a construir un sistema software es necesario conocer un lenguaje de programación, pero con eso no basta. Si se quiere que el sistema sea robusto y mantenible es necesario que el problema sea analizado y la solución sea cuidadosamente diseñada. Se debe seguir un proceso robusto, que incluya las actividades principales. 9.1 Visión General El proceso a seguir para realizar desarrollo orientado a objetos es complejo, debido a la complejidad que nos vamos a encontrar al intentar desarrollar cualquier sistema software de tamaño medio-alto. El proceso está formado por una serie de actividades y subactividades, cuya realización se va repitiendo en el tiempo aplicadas a distintos elementos. Las tres fases al nivel más alto son las siguientes: • Planificación y Especificación de Requisitos. • Construcción: La construcción del sistema. Las fases dentro de esta etapa son las siguientes: - Diseño de Alto Nivel. - Diseño de Bajo Nivel. - Implementación. - Pruebas. • Instalación. Fase de Planificación y Especificación de Requisitos Esta fase se corresponde con la Especificación de Requisitos tradicional ampliada con un Borrador de Modelo Conceptual y con una definición de Casos de Uso de alto nivel. En esta fase se decidiría si se aborda la construcción del sistema mediante desarrollo orientado a objetos o no, por lo que, en principio, es

26

independiente del paradigma empleado posteriormente. 9.2 Requisitos El formato del documento de Especificación de Requisitos no está definido en UML, pero se ha incluido este punto para resaltar que la actividad de definición de requisitos es un paso clave en la creación de cualquier producto software. Para entender y describir los requisitos la técnica de casos de uso constituye una valiosa ayuda. 9.3 Casos de Uso Un Caso de Uso es un documento narrativo que describe a los actores utilizando un sistema para satisfacer un objetivo. Es una historia o una forma particular de usar un sistema. Los casos de uso son requisitos, en particular requisitos funcionales. Un escenario es un camino concreto a través del caso de uso, una secuencia específica de acciones e interacciones entre los actores y el sistema. En un primer momento interesa abordar un caso de uso desde un nivel de abstracción alto, utilizando el formato de alto nivel. 9.3.1 Casos de Uso de Alto Nivel El siguiente Caso de Uso de Alto Nivel describe el proceso de sacar dinero cuando se está usando un cajero automático: - Caso de Uso: Realizar Reintegro - Actores: Cliente - Tipo: primario - Descripción: Un Cliente llega al cajero automático, introduce la tarjeta, se identifica y solicita realizar una operación de reintegro por una cantidad específica. El cajero le da el dinero solicitado tras comprobar que la operación puede realizarse. El Cliente coge el dinero y la tarjeta y se va. 9.3.2 Casos de Uso Expandidos Los casos de uso que se consideren los más importantes y que se considere que son los que más influencian al resto, se describen a un nivel más detallado: en el formato expandido. La principal diferencia con un caso de uso de alto nivel está en que incluye un apartado de Curso Típico de Eventos, pero también incluye otros apartados. 9.3.3 Identificación de Casos de Uso La identificación de casos de uso requiere un conocimiento medio acerca de los requisitos, y se basa en la revisión de los documentos de requisitos existentes, y en el uso de la técnica de brainstorming entre los miembros del equipo de desarrollo. identificación inicial de casos de uso hay dos métodos: a) Basado en Actores b) Basado en Eventos 9.3.4 Identificación de los Límites del Sistema Al definir los límites del sistema se establece una diferenciación entre lo que es interno y lo que es externo al sistema. El entorno exterior se representa mediante los actores. Ejemplos de sistemas son: • El hardware y software de un sistema informático. • Un departamento de una organización. • Una organización entera. 9.3.5 Tipos de Casos de Uso a) Según Importancia Para establecer una primera aproximación a la priorización de casos de uso que identifiquemos los vamos a distinguir entre: • Primarios. • Opcionales. b) Según el Grado de Compromiso con el Diseño 9.3.6 Consejos Relativos a Casos de Uso a) Nombre: El nombre de un Caso de Uso debería ser un verbo, para enfatizar que se trata de un proceso, por ejemplo: Comprar Artículos o Realizar Pedido. b) Alternativas equiprobables Cuando se tiene una alternativa que ocurre de manera relativamente ocasional, se indica en el apartado Cursos Alternativos. Pero cuando se tienen distintas opciones, todas ellas consideradas normales se puede completar el Curso Típico de Eventos con secciones adicionales. 9.4 Planificación de Casos de Uso según Ciclos de Desarrollo La decisión de qué partes del sistema abordar en cada ciclo de desarrollo se va a tomar basándose en los

27

casos de uso. Esto es, a cada ciclo de desarrollo se le va a asignar la implementación de uno o más casos de uso, o versiones simplificadas de casos de uso. Para tomar la decisión de qué casos de uso se van a tratar primero es necesario ordenarlos según prioridad. Las características de un caso de uso específico que van a hacer que un caso de uso tenga una prioridad alta son las siguientes: a. Impacto significativo en el diseño de la arquitectura. Por ejemplo, si aporta muchas clases al modelo del dominio o requiere persistencia en los datos. b. Se obtiene una mejor comprensión del diseño con un nivel de esfuerzo relativamente bajo. c. Incluye funciones complejas, críticas en el tiempo o de nivel elevado de riesgo. d. Implica bien un trabajo de investigación significante, o bien el uso de una tecnología nueva o arriesgada. e. Representa un proceso de gran importancia en la línea de negocio. f. Supone directamente un aumento de beneficios o una disminución de costes. 9.4.1 Caso de Uso Inicialización Prácticamente todos los sistemas van a tener un caso de uso Inicialización. Aunque puede ser que no tenga una prioridad alta en la clasificación realizada según el punto anterior, normalmente va a interesar que sea desarrollado desde el principio. 10 Fase de Construcción: Diseño de Alto Nivel En la fase de Diseño de Alto Nivel de un ciclo de desarrollo se investiga sobre el problema, sobre los conceptos relacionados con el subconjunto de casos de uso que se esté tratando. Se intenta llegar a una buena comprensión del problema por parte del equipo de desarrollo, sin entrar en cómo va a ser la solución en cuanto a detalles de implementación. 10.1 Actividades Las actividades de la fase de Diseño de Alto Nivel son las siguientes: 1. Definir Casos de Uso Esenciales en formato expandido. (si no están definidos ) 2. Refinar los Diagramas de Casos de Uso. 3. Refinar el Modelo Conceptual. 4. Refinar el Glosario. (continuado en posteriores fases) 5. Definir los Diagramas de Secuencia del Sistema. 6. Definir Contratos de Operación. 7. Definir Diagramas de Estados. (opcional) 10.2 Modelo Conceptual Una parte de la investigación sobre el dominio del problema consiste en identificar los conceptos que lo conforman. Para representar estos conceptos se va a usar un Diagrama de Estructura Estática de UML, al que se va a llamar Modelo Conceptual. 10.2.1 Identificación de Conceptos Para identificar conceptos hay que basarse en el documento de Especificación de Requisitos y en el conocimiento general acerca del dominio del problema. No es un método infalible, pero puede servir de guía para empezar. Para poner nombre a los conceptos se puede usar la analogía con el cartógrafo, resumida en los siguientes tres puntos: • Usar los nombres existentes en el territorio. • Excluir características irrelevantes. • No añadir cosas que no están ahí. 10.2.2 Creación del Modelo Conceptual Para crear el Modelo Conceptual se siguen los siguientes pasos: 1. Hacer una lista de conceptos candidato usando la Lista de Categorías de Conceptos de la Tabla 1 y la búsqueda de sustantivos relacionados con los requisitos en consideración en este ciclo. 2. Representarlos en un diagrama. 3. Añadir las asociaciones necesarias para ilustrar las relaciones entre conceptos que es necesario conocer. 4. Añadir los atributos necesarios para contener toda la información que se necesite conocer de cada concepto. 10.2.3 Identificación de Asociaciones Una asociación es una relación entre conceptos que indica una conexión con sentido y que es de interés en el conjunto de casos de uso que se está tratando.

28

10.2.4 Identificación de Atributos Es necesario incorporar al Modelo Conceptual los atributos necesarios para satisfacer las necesidades de información de los casos de uso que se estén desarrollando en ese momento. Los atributos deben tomar valor en tipos simples (número, texto, etc.), pues los tipos complejos deberían ser modelados como conceptos y ser relacionados mediante asociaciones. 10.3 Glosario En el glosario debe aparecer una descripción textual de cualquier elemento de cualquier modelo, para eliminar toda posible ambigüedad. Se ordena alfabéticamente por término. 10.4 Diagramas de Secuencia del Sistema Además de investigar sobre los conceptos del sistema y su estructura, también es preciso investigar en el Diseño de Alto Nivel sobre el comportamiento del sistema, visto éste como una caja negra. Una parte de la descripción del comportamiento del sistema se realiza mediante los Diagramas de Secuencia del Sistema. En cada caso de uso se muestra una interacción de actores con el sistema. En esta interacción los actores generan eventos, solicitando al sistema operaciones. Los casos de uso representan una interacción genérica. Una instancia de un caso de uso se denomina escenario, y muestra una ejecución real del caso de uso, con las posibles bifurcaciones y alternativas resueltas de forma particular. Un Diagrama de Secuencia de Sistema se representa usando la notación para diagramas de secuencia de UML 10.5 Contratos de Operaciones Una vez se tienen las Operaciones del Sistema identificadas en los Diagramas de Secuencia, se describe mediante contratos el comportamiento esperado del sistema en cada operación. Un Contrato es un documento que describe qué es lo que se espera de una operación. 10.5.1 Post-condiciones Las post-condiciones se basan en el Modelo Conceptual, en los cambios que sufren los elementos del mismo una vez se ha realizado la operación. Es mejor usar el tiempo pasado o el pretérito perfecto al redactar una post-condición, para enfatizar que se trata de declaraciones sobre un cambio en el estado que ya ha pasado. 10.6 Diagramas de Estados Para modelar el comportamiento del sistema pueden usarse los Diagramas de Estados que define UML (ver página 13). Se puede aplicar un Diagrama de Estados al comportamiento de los siguientes elementos: - Una clase software. - Un concepto. - Un caso de uso. 10.7 Fase de Construcción: Diseño de Bajo Nivel En la fase de Diseño de Bajo Nivel se crea una solución a nivel lógico para satisfacer los requisitos, basándose en el conocimiento reunido en la fase de Diseño de Alto Nivel. Los modelos más importantes en esta fase son el Diagrama de Clases de Diseño y los Diagramas de Interacción, que se realizan en paralelo y que definen los elementos que forman parte del sistema orientado a objetos que se va a construir. 10.7.1 Casos de Uso Reales Un Caso de Uso Real describe el diseño real del caso de uso según una tecnología concreta de entrada y de salida y su implementación. Si el caso de uso implica una interfaz de usuario, el caso de uso real incluirá bocetos de las ventanas y detalles de la interacción a bajo nivel con los widgets. 10.7.2 Diagramas de Interacción Los Diagramas de Interacción muestran el intercambio de mensajes entre instancias del modelo de clases para cumplir las post-condiciones establecidas en un contrato Hay dos clases de Diagramas de Interacción: 1. Diagramas de Colaboración. 2. Diagramas de Secuencia. 10.7.2.1 Creación de Diagramas de Interacción Para crear los Diagramas de Colaboración o de Secuencia se pueden seguir los siguientes consejos: • Crear un diagrama separado para cada operación del sistema en desarrollo en el ciclo de desarrollo actual. • Conocer: - Conocer datos privados encapsulados. - Conocer los objetos relacionados. - Conocer las cosas que puede calcular o derivar.

29

• Hacer: - Hacer algo él mismo. - Iniciar una acción en otros objetos. - Controlar y coordinar actividades en otros objetos. 10.8 Diagrama de Clases de Diseño Un Diagrama de Clases de Diseño muestra la especificación para las clases software de una aplicación. Incluye la siguiente información: • Clases, asociaciones y atributos. • Interfaces, con sus operaciones y constantes. • Métodos. • Navegabilidad. • Dependencias. A diferencia del Modelo Conceptual, un Diagrama de Clases de Diseño muestra definiciones de entidades software más que conceptos del mundo real. 10.8.1 Relaciones de Dependencia para Representar Visibilidad entre Clases Cuando una clase conoce a otra por un medio que no es a través de un atributo (una asociación con la navegabilidad adecuada), entonces es preciso indicar esta situación por medio de una dependencia. Hay otros tres tipos de visibilidad que hay que representar en el diagrama de clases mediante relaciones de dependencia: - Parámetro. - Local. - Global. 10.8.2 Navegabilidad La navegabilidad es una propiedad de un rol (un extremo de una asociación) que indica que es posible “navegar” unidireccionalmente a través de la asociación, desde objetos de la clase origen a objetos de la clase destino. La navegabilidad implica visibilidad, normalmente visibilidad por medio de un atributo en la clase origen. 10.8.3 Visibilidad de Atributos y Métodos Los atributos y los métodos deben tener una visibilidad asignada, que puede ser: + Visibilidad pública. # Visibilidad protegida. - Visibilidad privada. También puede ser necesario incluir valores por defecto, y todos los detalles ya cercanos a la implementación que sean necesarios para completar el Diagrama de Clases. 10.9 Otros Aspectos en el Diseño del Sistema En el diseño de un sistema es necesario también tomar decisiones a un nivel más alto sobre la descomposición de un sistema en subsistemas y sobre la arquitectura del sistema. Estas decisiones no se toman de forma distinta en un desarrollo orientado a objetos a como se llevan a cabo en un desarrollo tradicional. Fases de Implementación y Pruebas Una vez se tiene completo el Diagrama de Clases de Diseño, se pasa a la implementación en el lenguaje de programación elegido El programa obtenido se depura y prueba, y ya se tiene una parte del sistema funcionando que se puede probar con los futuros usuarios, e incluso poner en producción si se ha planificado una instalación gradual.

30

JOSE EDUARDO GARCIA ¿QUE ES UN INVENTARIO Y CUÁLES SON SUS TIPOS?

31

Un inventario representa la existencia de bienes muebles e inmuebles que tiene la empresa para comerciar con ellos, comprándolos y vendiéndolos tal cual o procesándolos primero antes de venderlos, en un período económico determinado. Deben aparecer en el grupo de Activo Circulante. La base de toda empresa comercial es la compra y venta de bienes o servicios; de aquí la importancia del manejo del inventario por parte de la misma. El inventario constituye las partidas del activo corriente que están listas para la venta, es decir, toda aquella mercancía que posee una empresa en el almacén valorada al costo de adquisición, para la venta o actividades productivas. Inventario de Mercancías: Lo constituyen todos aquellos bienes que le pertenecen a la empresa bien sea comercial o mercantil, los cuales los compran para luego venderlos sin ser modificados. En esta Cuenta se mostrarán todas las mercancías disponibles para la Venta. Las que tengan otras características y estén sujetas a condiciones particulares se deben mostrar en cuentas separadas, tales como las mercancías en camino (las que han sido compradas y no recibidas aún), las mercancías dadas en consignación o las mercancías pignoradas (aquellas que son propiedad de la empresa pero que han sido dadas a terceros en garantía de valor que ya ha sido recibido en efectivo u otros bienes). La contabilidad para los inventarios forma parte muy importante para los sistemas de contabilidad de mercancías, porque la venta del inventario es el corazón del negocio. Las empresas dedicadas a la compra y venta de mercancías, por ser esta su principal función y la que dará origen a todas las restantes operaciones, necesitaran de una constante información resumida y analizada sobre sus inventarios, lo cual obliga a la apertura de una serie de cuentas principales y auxiliares relacionadas con esos controles. Entre estas cuentas podemos nombrara las siguientes: Inventario Inicial: Representa el valor de las existencias de mercancías en la fecha que comenzó el periodo contable Compras: En la cuenta compras se incluye las mercancías compradas durante el periodo contable con el objeto de volver a venderlas con fines de lucro y que forman parte del objeto para el cual fue creada la empresa. Devoluciones en compra: Devoluciones en compra se refiere a la cuenta que es creada con el fin de reflejar toda aquella mercancía comprada que la empresa devuelve por cualquier circunstancia. Gastos de compras: Los gastos ocasionados por las compras de mercancías deben dirige a la cuenta titulada: Gastos de Compras. Esta cuenta tiene un saldo deudor y no entra en el Balance General. Ventas: Esta cuenta controlará todas las ventas de mercancías realizadas por la Empresa y que fueron compradas con este fin. Devoluciones en venta: 32

También tenemos Devoluciones en Venta, la cual está creada para reflejar las devoluciones realizadas por los clientes a la empresa. Mercancía de transito: En algunas oportunidades, especialmente si la empresa realiza compras en el exterior, nos encontramos que se han efectuado ciertos desembolsos o adquirido compromisos de pago (documentos o giros) por mercancías que la empresa compró pero que, por razones de distancia o cualquier otra circunstancia, aun no han sido recibidas en el almacén. Para contabilizar este tipo de operaciones se debe utilizar la cuenta: Mercancías en Tránsito. Inventario (Final) El Inventario Actual (Final) se realiza al finalizar el periodo contable y corresponde al inventario físico de la mercancía de la empresa y su correspondiente valoración. Clases de Inventarios: De acuerdo a las características de la empresa encontramos cinco tipos de inventarios. Inventario de Productos Terminados: Son todos aquellos bienes adquiridos por las empresas manufactureras o industriales, los cuales son transformados para ser vendidos como productos elaborados. Inventario de Productos en Proceso de Fabricación: Lo integran todos aquellos bienes adquiridos por las empresas manufactureras o industriales, los cuales se encuentran en proceso de manufactura. Su cuantificación se hace por la cantidad de materiales, mano de obra y gastos de fabricación, aplicables a la fecha de cierre. Inventario de Materias Primas: Lo conforman todos los materiales con los que se elaboran los productos, pero que todavía no han recibido procesamiento. Inventario de Suministros de Fábrica: Son los materiales con los que se elaboran los productos, pero que no pueden ser cuantificados de una manera exacta (Pintura, lija, clavos, lubricantes, etc.).

Sistemas de inventario: El Sistema de Inventario Perpetuo: En el sistema de Inventario Perpetuo, el negocio mantiene un registro continuo para cada artículo del inventario. Los registros perpetuos son útiles para preparar los estados financieros mensuales, trimestral o provisionalmente. EL negocio puede determinar el costo del inventario final y el costo de las mercancías vendidas directamente de las cuentas sin tener que contabilizar el inventario. El sistema 33

perpetuo ofrece un alto grado de control, porque los registros de inventario están siempre actualizados. El saldo de la cuenta inventario bajo el sistema perpetuo deberá resultar en el costo del inventario disponible en cualquier momento. Los registros de inventario perpetuo proporcionan información para las siguientes decisiones: •La mayoría de las tiendas de mobiliario, guarda la mercancía en sus almacenes, por lo tanto los empleados no pueden examinar visualmente la mercancía disponible y dar respuesta en ese mismo instante. El sistema perpetuo le indicará oportunamente la disponibilidad de dicha mercancía. •Los registros perpetuos alertan al negocio para reorganizar el inventario cuando éste se muestra bajo. •Si las compañías preparan los estados financieros mensualmente, los registros de inventario perpetuo muestran el inventario final existente, no es necesario un conteo físico en este momento; sin embargo, es necesario un conteo físico una vez al año para verificar la exactitud de los registros. Asientos bajo el Sistema Perpetuo En el sistema de inventario perpetuo, el negocio registra las compras de inventario cargando a la cuenta inventario, cuando el negocio realiza una venta, se necesitan dos asientos. La compañía registra la venta de la manera usual, carga a efectivo o a cuentas por cobrar y abona a ingresos por ventas el precio de las mercancías vendidas.

34

El Sistema de Inventario Periódico: En el sistema de inventario periódico el negocio no mantiene un registro continuo del inventario disponible, más bien, al fin del periodo, el negocio hace un conteo físico del inventario disponible y aplica los costos unitarios para determinar el costo del inventario final. El sistema periódico es conocido también como sistema físico, porque se apoya en el conteo físico real del inventario. El sistema periódico es generalmente utilizado para contabilizar los artículos del inventario que tienen un costo unitario bajo. Los artículos de bajo costo pueden no ser lo suficientemente valiosos para garantizar el costo de llevar un registro al día del inventario disponible. Asientos bajo el Sistema Perpetuo: En el sistema periódico, el negocio registra las compras en la cuenta compras (como cuenta de gastos); por su parte la cuenta inventario continua llevando el saldo inicial que quedó al final del período anterior.Un asiento de diario elimina el Saldo Inicial, abonándolo a Inventario y cargándolo a Ganancias y Pérdidas. Un segundo asiento de Diario establece el Saldo Final, basándose en el conteo físico. El cargo es a inventario, y el abono a Ganancias y Pérdidas. Estos asientos pueden realizarse en el proceso de cierre o como ajustes.

Carlos Álvarez H ¿Como fue la labor de los integrantes? Todos los integrantes trabajamos juntos, nos reunimos en múltiples ocasiones para compartir nuestro conocimiento e investigaciones y elaborar los pasos del problema planteado. Esta labor unida fortaleció el empiezo y trayectoria de nuestro proyecto y lograr nuestro objetivo. ¿Cual fue la parte más difícil y porque? La elaboración de la entrevista, esta fue una de las parte mas importantes del proyecto y por eso para mi fue algo difícil ya que ella tendría que darnos como resultado la información que necesitábamos obtener y por eso la formulación de las preguntas tendría que ser muy especificas para lograr el resultado esperado. ¿Cual fue la metodología para lograr los objetivos de este trabajo? El trabajo en grupo fue muy importante, el proyecto se dividió en partes para que cada integrante investigara lo asignado y luego reunirnos y comentar sobre nuestros conocimientos. Reparar los errores y compartir con el grupo la parte asignada. ¿Que nuevos conocimientos se lograron? Unas de las mejores metodologías en el desarrollo de sistemas es la de orientada a Objetos. Con este proyecto pude fortalecer mis conocimientos en la primera etapa de esta metodología el “Análisis”. Utilizar el diagrama UML en el análisis del problema es muy importante y de gran ayuda para su entendimiento. ¿Que conocimientos previos fueron esenciales? Todos los documentos de Cynergia y los laboratorios en clase, además los conocimientos previos obtenidos en los cursos de contabilidad en años anteriores, fueron de gran ayuda para elaboración del proyecto. ¿Que importancia tiene esta experiencia para su formación profesional? La elaboración de este proyecto obtuve como experiencia, la importancia que las empresas deben tener al manejar su sistema de inventario. Que unos de los mejores sistemas de inventarios mas fáciles y rápidos de utilizar es el sistemas Sistematizado. Que muchas empresas por ser pequeñas piensan que no lo deben utilizar o que no es necesario, pero en toda empresa el trabajo del inventario seria más eficiente con un sistema Sistematizado. ¿Que utilidad tiene el trabajo? Con este modelo de sistema de inventario sistematizado, podré utilizarlos para muchas empresas, mejorarlo y adaptarlo al dominio requerido. Con este análisis podré utilizarlo de referencia y guía para otros análisis OO y crear un programa en java e implementarlo en dicha empresa.

Hernán Franco G. ¿Como fue la labor de los integrantes? La labor de los integrantes fue bastante unidad ya que se preocuparon por dar lo mejor de ellos y de entregar los resultados en el tiempo estipulado. Solo que en algunos casos hubo que dejar tareas para apoyar a un compañero para seguir adelante. ¿Cual fue la parte más difícil y porque? La parte mas difícil fue la de encontrar una empresa ya que pasamos por muchas de ellas pero no llenaban las expectativas para el desarrollo del proyecto eso los considero lo mas difícil y además considera la implementación de lo los pasos orientado a objeto ya que había que tener cuidado en no cometer errores. ¿Cual fue la metodología para lograr los objetivos de este trabajo? Dividir en partes el trabajo ya que atacarlo de frente ere mas difícil y así fue como pudimos alcanzar los objetivos. ¿Que nuevos conocimientos se lograron? Acerca de cómo se maneja los inventario ya que esta un poco fuera de lugar en cuanto a ese tema, además he adquirido un poco mas de conocimiento acerca del modelamiento UML que no es hacer diagramas por hacer si no seguir unos paso para estar en lo correcto. ¿Que conocimientos previos fueron esenciales? Fueron los recursos ofrecidos por el profesor ya que sin ellos creo que nunca podría haber realizado este proyecto y mas aun entregar en forma correcta y con las especificaciones adecuadas. ¿Que importancia tiene esta experiencia para su formación profesional? Que para la resolver un problema OO. Es necesario seguir pasos y no ir a la programación de lleno ya que nos encontraremos con un mar de dudas. ¿Que utilidad tiene el trabajo? Que hay una forma que modela un sistema de un software desde una perspectiva específica mediante el Lenguaje UML.

Enocjahaziel Carrasco ¿Como fue la labor de los integrantes? La labor de cada integrante fue buena, apresar que todos teníamos que cumplir con asignaciones en otras materias se pudo lograr que cada uno de nosotros aportara de manera significativa a este proyecto ¿Cual fue la parte más difícil y porque? Lograr representar un modelo UML con la información obtenida de la entrevista y poder expresar esto en un modelo de uso. ¿Cual fue la metodología para lograr los objetivos de este trabajo? Divide y vencerás ¿Que nuevos conocimientos se lograron? Se obtuvieron muchos conocimientos acerca de inventario, lo implica hacer un inventario y los pasos que se debe tomar. Además de la responsabilidad que tiene la persona encargada de esto. También como hacer un modelo UML a partir de datos recabados. ¿Que conocimientos previos fueron esenciales? Fueron necesarios todos los conocimientos previos acerca de un modelo UML, Análisis orientado a objetos y la terminología; además de los conocimientos acerca de cómo realizar una encuesta obtenida en cursos anteriores. ¿Que importancia tiene esta experiencia para su formación profesional? La programación es más que solo sentarse a programar frente a una computadora y que para todo sistema es necesario hacer una investigación y tener idea de lo que se esta asiendo, Pude notar que la informática tiene muchos campos y implica el conocimiento de cada área. ¿Que utilidad tiene el trabajo? Tener la experiencia de para hacer un análisis orientado a objeto y poder sacar las clases independientemente del caso.

José García ¿Como fue la labor de los integrantes? Pienso que el trabajo en equipo, el esfuerzo de mis compañeros y el sacrificio de todos fue muy bueno, estoy satisfecho con la colaboración de mis compañeros de grupo gracias a ellos hemos terminado el proyecto. ¿Cual fue la parte más difícil y porque? Para mi la parte mas difícil fue entender esto de inventario, ya que el inventario utiliza muchos libros, diarios y cuentas que no conocía. Otro punto difícil fue comprender el modelo UML, pero poco a poco creo entender, y también fue un poco difícil formular las preguntas necesarias para la entrevista. ¿Cual fue la metodología para lograr los objetivos de este trabajo? Lo primero que hicimos fue dividir el trabajo para que cada uno fuera leyendo un tema luego intercambiamos ideas sobre los diferentes temas para poder entender cada uno, después unimos los conocimientos y realizamos la entrevista y estudiamos los resultados. Y al final nos centramos en el lenguaje UML, para poder pasar a la construcción del trabajo escrito. ¿Que nuevos conocimientos se lograron? Para mi el principal conocimiento fue el conocimiento de los modelos UML, otros de los conocimientos que creo importante es el conocimiento a fondo de como se debe realizar un inventario, los tipos de inventarios y sus respectivos sistemas. ¿Que conocimientos previos fueron esenciales? Unos de los conocimientos previos fueron las distintas referencias ofrecidas por el facilitador, a parte de esos estuve leyendo viejos apuntes sobre los inventarios y un folleto que hablaba sobre UML. ¿Que importancia tiene esta experiencia para su formación profesional? Creo que tiene una importancia esencial en mi formación profesional, ya que trata de un tema que es de vital importancia en cualquiera empresa, como lo es el inventario ya que es el corazón de la empresa, y sobre todo el lenguaje UML importante en el moldeamiento unificado de los sistemas, gracias a este lenguaje haríamos un software tan adecuado y eficiente a la necesidad de la empresa. ¿Que utilidad tiene el trabajo? Pienso que es importante en algún momento que necesite realizar un modelo de inventario en alguna empresa que preste mis servicios, creo que es de gran ayuda a alguna empresa en general.

CONCLUCIONES Este trabajo fue realizado a base de conocimiento en el tema sobre el inventario el cual fue estudiado a fondo con sus distintos tipos, clases y sistemas de inventario. Analizamos sobre el tema y comparamos con los resultados obtenidos en la entrevista para realizar un modelo unificado para la empresa, estudiamos los resultados y buscamos un sistema adecuado de inventario a la empresa entrevistada para que de tal manera la empresa pueda realizar un inventario eficiente que le permita saber si obtiene ganancia o perdida y que permita mejorar su sistema de inventario También concluimos con una de las etapas del la metodología de orientación a objetos, gracias al bosquejo del lenguaje UML, que nos permitió visualizar, especificar y documentar cada una de las partes que comprende el análisis del sistema para dicha empresa La síntesis realizada por cada uno de los integrantes, pudo afianzar el conocimiento en cada uno de las áreas del análisis. También cada una de las áreas, así como la utilización del modelo UML.