32
UNIVERSIDAD DE PANAMÁ CENTRO REGIONAL UNIVERSITARIO DE VERAGUAS FACULTAD DE INFORMÁTICA ELECTRÓNICA Y COMUNICACIÓN LICENCIATUARA EN INFORMÁTICA PARA LA GESTIÓN EDUCATIVA Y EMPRESARIAL PROGRAMACIÓN ORIENTADA A OBJETOS PROYECTO #1 PROFESOR: DIEGO SANTIMATEO INTEGRANTES: ATENCIO, ADELAIDA 9-721-1818 EVELIO DÍAZ 9-719-1610 GLADYS RODRÍGUEZ 9-722-1190 MADRID, NORIEL 8-777-2199

Proyecto #2

Embed Size (px)

DESCRIPTION

Este es nuestro proyecto, espero lo lean y manden sus críticas constructivas. Adelaida, Evelio, Gladys, Noriel

Citation preview

Page 1: Proyecto #2

UNIVERSIDAD DE PANAMÁCENTRO REGIONAL UNIVERSITARIO DE VERAGUAS

FACULTAD DE INFORMÁTICA ELECTRÓNICA Y COMUNICACIÓNLICENCIATUARA EN INFORMÁTICA PARA LA GESTIÓN

EDUCATIVA Y EMPRESARIAL

PROGRAMACIÓN ORIENTADA A OBJETOSPROYECTO #1

PROFESOR:DIEGO SANTIMATEO

INTEGRANTES:

ATENCIO, ADELAIDA 9-721-1818EVELIO DÍAZ 9-719-1610

GLADYS RODRÍGUEZ 9-722-1190MADRID, NORIEL 8-777-2199

II SEMESTRE

26 DE SEPTIEMBRE DE 2008

Page 2: Proyecto #2

INTRODUCCIÓN

La programación Orientad a Objeto es una metodología de programación basada en objetos y en el envío de mensajes entre estos. La misma se originó en el año 1991 por James Gosling que se basó en programas dirigidos al funcionamientos de Electrodomésticos.

La programación Orientada a Objetos es aplicada a una gran cantidad de actividades, es por eso que nuestra investigación se basará en el funcionamiento de un Inventario de una Empresa .

La base de toda Empresa Comercial es la Compra y Venta de Mercancías. Por ende es muy importante analizar el manejo de un Inventario.

El propósito de nuestra investigación consiste en desarrollar un análisis y diseño OO de un sistema de Inventario.

Tomamos como modelo de Empresa a la Cooperativa Juan XXIII que nos brindó la información necesaria para comprender el funcionamiento de un sistema automatizado de inventario, además de habernos indicado los documentos de Entrada y Salida que ellos utilizan para actualizar el sistema.

A partir de esta información creamos un problema el cual nos propusimos desarrollar en este proyecto.

Para dar solución al problema creamos una pequeña Empresa ficticia que nos ayudará a la hora de realizar el análisis y el diseño OO.

Page 3: Proyecto #2

CONTENIDO DE LA INVESTIGACIÓN

Problema:

Creación de un Sistema de Inventario automatizado para registrar los datos de entrada y salida de mercancía de una Empresa que se dedica a la compra y venta de útiles de Escolares.

Requisitos del problema a resolver:

Determinar la cantidad de Artículos en existencia. Dependiendo del código de Artículo determinar la cantidad en existencia del mismo. Determinar el valor de inventario de cada producto. Determinar el valor de inventario de todos los artículos existentes en el almacen.

Encuesta Aplicada para ampliar los conocimientos:

Para la determinación de las clases del dominio aplicamos encuestas, que nos permitieron aplicar nuestros conocimientos, para así determinar específicamente cuales son las clases del problema bajo estudio.

La siguiente encuesta muestra la información que La Entrevistada nos Facilitó.

Page 4: Proyecto #2

UNIVERSIDAD DE PANAMÁCENTRO REGIONAL UNIVERSITARIA DE VERAGUAS

FACULTAD DE INFORMÁTICA, ELECTRÓNICA Y COMUNICACIÓN

“Marque con un gancho ( ) la respuesta seleccionada”

¿Qué tipo de Inventario realiza la Empresa?

Inventario de Mercancías. Inventario de Productos Terminados. Inventario de Productos en Proceso de Fabricación. Inventario de Materias Primas. Inventario de Suministros de Fábrica. Otros:________________________________________________

¿El Inventario se lleva en forma Automatizada o Manual? Automatizada .

3. ¿Cada que tiempo se realizan inventarios físicos?

Diario Semanal Mensual Anual Otros:________________________________________________

4. ¿Qué documentos de entrada y de salida utilizan para actualizar el inventario? - P.D.T. - Ordenes de compra - Ordenes de Venta -Facturas -Dev. En Compra, Dev. En ventas

Muchas Gracias

Consulta a Encargados (as) de Sistema de Administración de Inventario de la Empresa; centrados en los componentes , transacciones, usuarios,

características, relaciones y requerimientos.

Page 5: Proyecto #2

COOPERATIVA DE SERVICIOS MÚLTIPLES JUAN XXIII

La entrevista fue aplicada a la Administradora Judith Ortega, que nos dio a conocer que en la Empresa se realizan inventarios de mercancías que se llevan de forma automatizada. Estos inventarios se hacen diariamente al final de la jornada.Para la actualización del Inventario utilizan documentos de entrada y salida.Estos documentos son:

Entrada: Ordenes de Compra. Devoluciones en Ventas.

Salida: Ordenes de Venta. Devoluciones en Compra.

Para acceder al inventario utilizan el P.D.T (Pos DataTraveler)que es utilizado para la actualización del inventario de mercancías.

TABLA DEMOSTRATIVA DE RESULTADOS

INTERROGANTES RESPUESTAS

¿Que tipo de Inventario realiza la Empresa? Inventario de Mercancías.

¿El Inventario se lleva en forma Automatizada o Manual?

Automatizada

¿Cada que tiempo se realizan inventarios físicos?

Diario

¿Qué documentos de entrada y de salida utilizan para actualizar el inventario?

Ordenes de compras. Ordenes de ventas. Facturas Devoluciones en compras. Devoluciones en Ventas.

El resultado de esta encuesta nos indicaron que necesitamos de tres clases que son:

Una clase llamada Inventario que contiene subclases:

- EntradaMerc: Dentro de esta clase se va a determinar a través del código del artículo la suma de los artículos nuevos con los artículos existentes y de igual manera se sumarán los precios.

SalidaMerc : En esta clase se va a determinar a través del código del producto la resta de los artículos nuevos con los artículos existentes y de igual manera se restarán los precios.

Relaciones o asociaciones entre clases: A la clase Inventario se le sumarán los datos de la clase EntradaMerc. A la clase Inventario se le restará los datos de la clase SalidaMerc.

Esta relación se da de de uno a varios, ya que la clase Inventario se relaciona con la clase EntradaMerc y SalidaMerc.

Page 6: Proyecto #2

Identificación de los atributos:

ATRIBUTOS DE CADA CLASE

Class Inventario Class EntradaMerc Class SalidaMerc

nombreArt codigoArt precioArt cantidadArt

codigoArt precioArt cantidadArt

codigoArt precioArt cantidadArt

Para un mejor entendimiento de como entran y salen las mercancías de una empresa colocamos el siguiente Diagrama:

DIAGRAMA CASO USO

Class Inventario

relación

Class EntradaMerc Class SalidaMerc

Dev en venta

Realiza compra

Devuelve la compra

Vendedor de otra Emp El trabajador de nuestra empresa le pasa la factura al Administrador

Facturas

Orden de Compra

Trabajador Emp.

Dev en compra

Cajero

cliente Devuelve la compra

Vendedor

Facturas

Orden de ventaOrden de compra

Administrador

Page 7: Proyecto #2

DIAGRAMA UML

Inventario+String+ String Codigo+ float Precio+ int Cantidad

+SumarDatos()+RestarDatos()

1 .1 .

1 ..*1 ..*

EntradaArt

+ String Codigo+ float Precio+Cantidad

+SumarDatos()

SalidaArt

+ String Codigo+ float Precio+Cantidad

+RestarDatos()

Interactúan entre s i para actualización del inventario(los datos de la clase principal se modifican en la subclase)

A so c ia c ió n

C la se B a s ic a

Page 8: Proyecto #2

SINTESIS

1. Inventario Comercial

La base de toda empresa comercial es la compra y venta de bienes o servicios; de aquí es la importancia del manejo del inventario. Este manejo contable permitirá a la empresa mantener el control de la situación económica de la empresa.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.

2. ¿Qué son los inventarios?

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.

Las empresas dedicadas a la compra y venta de mercancías, por ser esta su principal función 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. Entres estas cuentas podemos nombrar las siguientes:

Inventario (inicial)

Compras

Devoluciones en compra

Gastos de compras

Ventas

Devoluciones en ventas

Mercancías en tránsito

Mercancías en consignación

Inventario (final)

3. Sistemas de inventario

El Sistema de Inventario Perpetuo:

En el sistema de Inventario Perpetuo proporciona información actualizada en cuanto a cada artículo del inventario. Se usa cuando la gerencia desea información al corriente sobre el inventario cada día o cada semana.

Page 9: Proyecto #2

En este método de inventario se lleva un registro de tal forma que muestra a cada momento cual es la existencia y el importe o valor de los artículos en existencia, las compras y las ventas de inventarios se registran según vayan ocurriendo las transacciones o movimientos.

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 de Inventario Periódico:

En el sistema de inventario periódico no se mantiene un registro continuo del inventario, sino se hace al final del periodo.

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. Para usar el sistema periódico con efectividad, el propietario debe tener la capacidad de controlar el inventario mediante la inspección visual. Por ejemplo, cuando un cliente le solicita ciertas cantidades disponibles, el dueño o administrador pueden visualizar las mercancías existentes.

4. Clases de Inventarios:

De acuerdo a las características de la empresa encontramos cinco tipos de inventarios.

Inventario de Mercancías:

Son todos aquellos bienes que le pertenecen a la empresa bien sea comercial o mercantil, los cuales los compran para luego venderlos sin ser modificados.

Inventario de Productos Terminados:

Son todos aquellos bienes adquiridos por las empresas manufactureras o industriales a elaborado, los cuales son disponibles para la venta.

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.).

Page 10: Proyecto #2

5. Métodos de costeo de inventarios:

Los negocios multiplican la cantidad de artículos de los inventarios por sus costos unitarios para determinar el costo de los inventarios. Los métodos de costeo de inventarios son: costo unitario específico, costo promedio ponderado, costo de primeras entradas primeras salidas (PEPS), y costo de últimas entradas primeras salidas (UEPS).

Costo Unitario Específico: Algunas empresas tratan con artículos de inventario que pueden identificarse de manera individual, como los automóviles, joyas y bienes raíces. Estas empresas costean, por lo general, sus inventarios al costo unitario específico de la unidad en particular. Por ejemplo, un concesionario de automóviles tiene dos vehículos en exhibición; un modelo "x" que cuesta $14,000 y un modelo "y" equipado que cuesta $17,000. Si el concesionario vende el modelo equipado en $19,700; el costo de mercancía vendida es de $17,000 el costo específico de la unidad; el margen bruto en esta venta es de $2,700 ($19,700 - $17,000). Si el automóvil "x" es el único que queda en el inventario disponible al final del periodo, el inventario final es de $14,000.

El método de primeras entradas , primeras salidas : Este método nos representan un método donde el costo de la mercancía vendida es tomada de los primeros costo de las unidades compradas por ejemplo se compro 100 galones de gasolina B/ 2.50 y luego se compro 100 a B/ 3.00 la primera ventas de las gasolina se asumen que son las que se compraron a B/ 2.50 para que el valor del inventario sea de B/ 3.00 por galón .

Costo de Últimas Entradas, Primeras Salidas (UEPS): El método Ultimo en entrar, primeras en salir. Es uno de los métodos más interesantes en la valuación del inventario. El flujo de costos puede ser más significativo que el flujo físico de las mercancías. Bajo este método, los últimos costos que entran al inventario son los primeros costos que salen al costo de mercancías vendidas. Este método deja los costos más antiguos (aquellos del inventario inicial y las compras primeras del periodo) en el inventario final.

Método de costo de promedio ponderado : Este método aunque no es usado frecuentemente es otro método de control de inventario, este se calcula sumando el costo de mercancía inicial mas(+) los costos de compras (costo de mercancía disponible) y estos se dividen entre las cantidades de unidades que se han adquirido desde el saldo inicial, luego se calcula el costo de inventario final dividiendo la cantidad de unidades existentes entre el CPP, el resultado se le resta a costo de mercancía disponible. Dando por resultado el costo de venta.

Método de promedio simple: Este método funciona de la siguiente manera se suma los costo de mercancías adquiridas y se divide entre la cantidad pedidos o partidas que se hayan realizado en el periodo, ya obtenido el promedio se calcula el costo de inventario final ,que resulta de la división de la cantidad de artículos entre el promedio, el resultado se le resta al costo de mercancía disponible dando como resultado el costo de venta.

. MODELOS DE CLASES

Page 11: Proyecto #2

Los elementos de un diagrama de calase son las Clases las cuales son representadas por atributos , métodos y visibilidad .y las relaciones que son representadas por herencias, Composición , Agregación ,asociación y uso.

La clase : Es la unidad básica que encapsula toda la información de un objeto , esta en UML es representada por un cuadro con tres campos , uno para el nombre de la clase ,otro para los atributos y uno para las operaciones y métodos , por ejemplo una clase producto puede contener un código, una cantidad y un precio como atributo y un precio de venta como operación .

Los atributos : Son la característica de una clase y pueden ser públic, private y protected, Atributos públic son accesibles desde cualquiera otra clase . Atributos private solo son accesibles des un método su clase . Atributos protected solo son accesibles des un método su clase o una subclase que se derive .

Los métodos: Son las operaciones de una clase, y al igual que los atributos pueden se públic, private y protected, utilizando las mismas reglas de acceso.

Relaciones entre clases : Estas pueden ser por herencias, Composición , Agregación ,asociación y uso.

Por Herencia : en esta una subclase hereda los métodos y atributos de una Super clase al igual que sus características.

Por agregación :son utilizadas para modelar objetos complejos y pueden ser por valor y por referencias . La agregación por valor es una relación estática y pueden ser por valor y por referencia

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. Esta es llamada Composición.

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. Esta es llamada Agregación.

Por Asociación: La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si.

Dependencia o Instanciación (uso): Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

7. 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 (aún no han sido definidos, es decir, sin implementación). La única forma de utilizarla es definiendo subclases, que implementan los métodos abstractos

Page 12: Proyecto #2

definidos.

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.

8. 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 . Ambos usos son distintos conceptual mente, mientras los primeros modelan elementos del dominio los segundos presentan los elementos de la solución software. Ambos tipos de diagramas comparten una parte de la notación para los elementos que los forman (clases y objetos) y las relaciones que existen entre los mismos (asociaciones). Sin embargo, hay otros elementos de notación que serán exclusivos de uno u otro tipo de diagrama.

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. Una clase puede representarse de forma esquemática, con los atributos y operaciones suprimidos, siendo entonces tan solo un rectángulo con el nombre de la clase.

Objetos: Un objeto se representa de la misma forma que una clase.

Asociaciones: Las asociaciones entre dos clases se representan mediante una línea que las une. La línea puede tener una serie de elementos gráficos que expresan características particulares de la asociación.

a) 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. Se puede añadir un pequeño triángulo negro sólido que indique la dirección en la cual leer el nombre de la asociación. Los nombres de las asociaciones normalmente se incluyen en los modelos para aumentar la legibilidad.

b) 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. Puede expresarse de las siguientes formas: • Con un número fijo: 1.• Con un intervalo de valores: 2..5.• Con un rango en el cual uno de los extremos es un asterisco. Significa que es un intervalo abierto. Por ejemplo, 2..* significa 2 o más.• Con una combinación de elementos como los anteriores separados por comas: 1, 3..5, 7, 15..*.• Con un asterisco: * . En este caso indica que puede tomar cualquier valor (cero o más).

c) Roles

Page 13: Proyecto #2

Para indicar el papel que juega una clase en una asociación se puede especificar un nombre de rol. Se representa en el extremo de la asociación junto a la clase que desempeña dicho rol.

d) 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”.

e) 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. Tanto la línea como el rectángulo de clase representan el mismo elemento conceptual: la asociación. Por tanto ambos tienen el mismo nombre, el de la asociación. Cuando la clase asociación sólo tiene atributos el nombre suele ponerse sobre la línea (como ocurre en el ejemplo de la Figura 11). Por el contrario, cuando la clase asociación tiene alguna operación o asociación propia, entonces se pone el nombre en la clase asociación y se puede quitar de la línea.

f) AsociacionesN-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. Si se muestra multiplicidad en un rol, representa el número potencial de tuplas de instancias en la asociación cuando el resto de los N-1 valores están fijos.

g) Navegabilidad En un extremo de una asociación se puede indicar la navegabilidad mediante una flecha. Significa que es posible "navegar" desde el objeto de la clase origen hasta el objeto de la clase destino.

9. 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”. Si se tiene una relación de herencia con varias clases subordinadas, pero en un diagrama concreto no se quieren poner todas, esto se representa mediante puntos suspensivos.

10. 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. Se representa con una barra “/” precediendo al nombre del elemento derivado.

11. Elementos comunes a todos los diagramas

Notas Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama. Puede contener restricciones, comentarios, el cuerpo de un

Page 14: Proyecto #2

procedimiento, etc.

DependenciasLa relación de dependencia entre dos elementos de un diagrama significa que un cambio en el elemento destino puede implicar un cambio en el elemento origen (por tanto, si cambia el elemento destino habría que revisar el elemento origen). Una dependencia se representa por medio de una línea de trazo discontinuo entre los dos elementos con una flecha en su extremo. El elemento dependiente es el origen de la flecha y el elemento del que depende es el destino (junto a él está la flecha).

12. UML (Unified Modeling Language o Lenguaje Unificado de Modelado) : Es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos.

Esta notación ha sido amplia mente aceptada debido al prestigio de sus creadores y debido a que incorpora las principales ventajas de cada uno de los métodos. Con UML se fusiona la notación de estas técnicas para formar una herramienta compartida entre todos los ingenieros software que trabajan en el desarrollo orientado a objetos.

Uno de los objetivos principales de la creación de UML era posibilitar el intercambio de modelos entre las distintas herramientas CASE orientadas a objetos del mercado.

13. Modelo Dinámicos

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.

Los diagramas de actividades que sirven fundamentalmente para modelar el flujo de control entre actividades. Gráficamente un diagrama de actividades será un conjunto de arcos y nodos. Desde un punto de vista conceptual, el diagrama de actividades muestra cómo fluye el control de unas clases a otras con la finalidad de culminar con un flujo de control total que se corresponde con la consecución de un proceso más complejo. Por este motivo, en un diagrama de actividades aparecerán acciones y actividades correspondientes a distintas clases. Colaborando todas ellas para conseguir un mismo fin.

Estados de actividad y estados de acción

Page 15: Proyecto #2

La representación de ambos es un rectángulo con las puntas redondeadas, en cuyo interior se representa bien una actividad o bien una acción. La forma de expresar tanto una actividad como una acción, no queda impuesta por UML, se podría utilizar lenguaje natural, una especificación formal de expresiones, un metalenguaje, etc. 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”.

En cambio un estado de actividad, sí puede descomponerse en más sub-actividades representadas a través de otros diagramas de actividades. Además estos estados sí pueden ser interrumpidos y tardan un cierto tiempo en completarse. En los estados de actividad podemos encontrar otros elementos adicionales como son: acciones de entrada (entry) y de salida (exit) del estado en cuestión, así como definición de submáquinas.

Transiciones Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de acción. Esta transición se produce como resultado de la finalización del estado del que parte el arco dirigido que marca la transición. Como todo flujo de control debe empezar y terminar en algún momento, podemos indicar esto utilizando dos disparadores de inicio y fin tal.

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, las guardas de la bifurcación han de ser excluyentes y contemplar todos los casos ya que de otro modo la ejecución del flujo de control quedaría interrumpida. Para poder cubrir todas las posibilidades se puede utilizar la palabra ELSE, para indicar una transición obligada a un determinado estado cuando el resto de guardas han fallado. En la Figura 24 podemos ver un ejemplo de bifurcación.

División y unión No sólo existe el flujo secuencial y la bifurcación, también hay algunos casos en los que se requieren tareas concurrentes. 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.

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. Cada calle representa a la parte de la organización responsable de las actividades que aparecen en esa calle.

Page 16: Proyecto #2

14. 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

15. 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. Si se sigue un proceso de desarrollo que se ocupa de plantear cómo se realiza el análisis y el diseño. Especialmente cuando se trata de un equipo de desarrollo formado por varias personas.

La notación que se usa para los distintos modelos, tal y como se ha dicho anteriormente, es la proporcionada por UML, que se ha convertido en el estándar de facto en cuanto a notación orientada a objetos. El uso de UML permite integrar con mayor facilidad en el equipo de desarrollo a nuevos miembros y compartir con otros equipos la documentación, pues es de esperar que cualquier desarrollador versado en orientación a objetos conozca y use UML (o se esté planteando su uso). Se va a abarcar todo el ciclo de vida, empezando por los requisitos y acabando en el sistema funcionando, proporcionando así una visión completa y coherente de la producción de sistemas software. Donde lo más importante es el resolver una necesidad del usuario/cliente.

Visión General Se presenta una visión general para poder tener una idea del proceso a alto nivel, y más adelante se verán los pasos que componen cada fase. Las tres fases al nivel más alto son las siguientes: • Planificación y Especificación de Requisitos: Planificación, definición de requisitos, construcción de prototipos, etc. • Construcción: La construcción del sistema. Las fases dentro de esta etapa son las siguientes:      - Diseño de Alto Nivel: Se analiza el problema a resolver desde la perspectiva de los usuarios y de las entidades externas que van a solicitar servicios al sistema.

Page 17: Proyecto #2

     - Diseño de Bajo Nivel: El sistema se especifica en detalle, describiendo cómo va a funcionar internamente para satisfacer lo especificado en el Diseño de Alto Nivel.      - Implementación: Se lleva lo especificado en el Diseño de Bajo Nivel a un lenguaje de programación.      - Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el software funciona correctamente y que satisface lo especificado en la etapa de Planificación y Especificación de Requisitos. • Instalación: La puesta en marcha del sistema en el entorno previsto de uso.

Page 18: Proyecto #2

COMENTARIOS DE LOS INTEGRANTE DEL GRUPO

PREGUNTAS:

¿Como fue la labor de los integrantes?. ¿Cual fue la parte más difícil y porqué? ¿Cual fue la metodología para lograr el objetivo de este trabajo? ¿Que nuevos conocimientos se lograron? ¿Que conocimientos previos fueron necesarios? ¿Que importancia tiene esa experiencia para su formación profesional? ¿Que utilidad tiene el trabajo realizado?

NOMBRE DE LOS INTEGRANTES RESPUESTAS A LAS PREGUNTAS

Adelaida Atencio

La labor de los integrantes fue muy buena, porque todos estuvimos pendiente del trabajo a realizar.La parte más difícil fue la de entender específicamente lo que se debe lograr con la realización del trabajo, ya que si no se tiene claro cual es el objetivo del mismo, nunca se le dará solución.La metodología fue seguir los pasos para la realización de un análisis OO; y leer la información brindada por el Facilitador.Los conocimientos logrados fueron los siguientes:- Conocer el funcionamiento de una empresa - Analizar como acceder a un inventario a través de la entrada y salida de productos en la misma.- Entender un poco mejor como se crea un diagrama UML.- Ver como se aplica el análisis a la hora de resolver un problema.Para resolver este proyecto necesité conocimientos previos como lo es el análisis OO y la distinción entre clases,atributos, objetos, etc.Esta experiencia es muy importante para mi futuro porque mi carrera necesitará mucho del análisis ya que posiblemente mi área de trabajo será una Empresa.Este trabajo es muy útil porque para yo poder crear un sistema para una Empresa necesito aplicar todo esto y mucho más.

Evelio Díaz Este trabajo fue elaborador en grupo y todos trabajamos por igual ya sea en la investigación como el análisis, al igual que la parte económica.

La parte mas difícil fue la creación del modelo de diagrama UML ya que teníamos poco conocimiento sobre el mismo.

La metodología utilizada en este trabajo fue la de investigación y el seguimientos de los pasos del análisis OO .

a través de este trabajo hemos adquirido muchos conocimientos sobre el diseño orientado a objeto representado en UML , y todo lo necesario para diseñar un sistema de inventario automatizado y los distintos métodos de recolección de datos como el PDT que es un sistema de captura de datos de los artículos a través

Page 19: Proyecto #2

del código de barra, este sistema es utilizado en empresas como la Cooperativa Juan XXIII.

Esta investigación exigía tener conocimientos mínimos de el análisis orientación a objetos.

Esta experiencia nos a ayudado a fortalecer nuestro conocimiento sobre mercadeo y sobre la estructuración de un diseño basado en la orientación a objeto, los mismos nos ayudaran en nuestro futuro como profesionales al momento de trabajar con este tipo de diseños.

Este trabajo nos sera útil al momento de desarrollar programas en el curso y en el futuro como programadores profesionales.

Gladys Rodríguez En este proyecto fue realizado en conjunto al realizar desde las entrevistas hasta el documento final;

La parte más difícil fue el análisis OO; pues no sabíamos en que basarnos para hacer dicho análisis; Así que hicimos una empresa ficticia .

Objetivo: Realizamos una metodología de Análisis que contiene documentado todas las especificaciones de Inventario de una empresa en particular.

Conocimientos: Que debemos realizar un Análisis y después y Diseño de UML donde se pueden ver con más claridad los atributos, métodos, clases incluyendo el main; en nuestro caso el UML era modelo para un Sistema de Inventario de Mercancía.

Conocimientos previos: Basamos en la Encuesta realizada a la Administradora de la Empresa visitada.

Experiencia: Diseñar un UML.

Importancia: Saber como se maneja un Sistema de inventario y así ser competitivos en el campo laboral.

Utilidad: Nos sirve para cuando debemos desarrollar un problema en particular y saber las necesidades de los clientes o usuarios.

Noriel Madrid La labor de cada integrante del grupo fue muy buena ya que todos participamos en la realización de cada punto que se solicito.

La parte mas difícil del proyecto fue la confección del diagrama UML , porque no teníamos bien claro los atributos y los métodos de cada clase que se necesitaban en su confección.

Se realizo una investigación en varios locales de Santiago, de todas las partes donde fuimos la Cooperativa Juan XXIII nos dio la información necesaria que nos ayudo a adquirir más conocimiento o a tener más idea en la confección del diagrama UML.

Conocimiento referentes al manejo de inventarios de articulo en el

Page 20: Proyecto #2

flujo de entrada y salida de los mismos.

Debíamos conocer por lo menos conocer el análisis orientado a objeto.

En el futuro nos ayudan a la hora de hacer un diseño de programación a objeto en una empresa.

Este trabajo nos sera útil al momento de desarrollar sistemas orientados a objetos en este curso o en un trabajo futuro.

Page 21: Proyecto #2

GLOSARIO DE TÉRMINOS

Inventario (inicial): El 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 incluyen 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 dirigirse 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 ventas: La cual está creada para reflejar las devoluciones realizadas por los clientes a la empresa.

Mercancías en tránsito: 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.

Mercancías en consignación: Por otro lado tenemos la cuenta llamada Mercancía en Consignación, que no es más que la cuenta que reflejará las mercancías que han sido adquiridas por la empresa en "consignación", sobre la cual no se tiene ningún derecho de propiedad, por lo tanto, la empresa no está en la obligación de cancelarlas hasta que no se hayan vendido.

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. Al relacionar este inventario con el inicial, con las compras y ventas netas del periodo se obtendrá las Ganancias o Pérdidas Brutas en Ventas de ese período.

modelo: Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle.

Diagrama: una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos.

Registro: Es una pequeña unidad de almacenamiento destinada a contener cierto tipo de datos. Puede estar en la propia memoria central o en unidades de memoria de acceso rápido.

Clase: En programación orientada a objetos, una clase es un nivel más alto que un objeto, de hecho la relación entre ambos es el concepto principal y base de todo el resto. Por decirlo de alguna manera, un objeto es más tangible que una clase, que es un nivel más abstracto (sin ninguna relación con lo que son las clases abstractas, pues tipos de clases hay varios).

Page 22: Proyecto #2

Métodos: Un método consiste generalmente de una serie de sentencias para llevar a cabo una acción, un juego de parámetros de entrada que regularán dicha acción y, posiblemente, un valor de salida (o valor de retorno) de algún tipo. El propósito de los métodos es el de proveer un mecanismo para acceder (leer o modificar) los datos privados que se encuentran almacenados en un objeto o clase.

UML (Unified Modeling Language): es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estándar de facto de la industria, debido a que ha sido impulsado por los autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Estos autores fueron contratados por la empresa Rational Software Co. para crear una notación unificada en la que basar la construcción de sus herramientas CASE. En el proceso de creación de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, así como grupos de analistas y desarrolladores.

Herencia (Especialización/Generalización): Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected).

Page 23: Proyecto #2

CONCLUSIÓN

En este proyecto de programación Orientada Objetos, comprendimos que para hacer un Modelo de UML se necesita primero un Análisis OO.

Para realizar un diseño UML se necesita aplicar una encuesta a expertos, en nuestro caso a la Administradora de la Cooperativa Juan XXIII; para así tener un conocimiento más amplio sobre el problema a solucionar.

Para hacer un Análisis OO necesitamos tener un problema a resolver; por lo tanto nosotros nos basamos en una Empresa ficticia donde implementamos un Sistema de Inventario y después el modelo de UML.