UNIVERSIDAD DE PANAMÁ CENTRO REGIONAL UNIVERSITARIO DE VERAGUAS FACULTAD DE INFORMÁTICA ELECTRÓNICA Y COMUNICACIÓN (FIEC) INF.

222 PROGRAMACIÓN ORIENTADA A OBJETOS PROYECTO #1

“ANÁLISIS Y DISEÑO CON ORIENTACIÓN A OBJETOS”

PROFESOR DIEGO SANTIMATEO ESTUDIANTE ÁNGEL AGUILAR 8-821-2269 NORBERTO DELGADO 9-731-110 FERNANDO VILLARREAL 6-711-1562 II AÑO II SEMESTRE

2008

INTRODUCCIÓN

En nuestro diario vivir como estudiantes existen situaciones en las que por apuro o escasez de tiempo terminamos a la ligera las asignaciones y no tenemos en cuenta que generalmente dentro de los parámetros de un programador o diseñador de software, es que se deja pasar por alto un aspecto muy importante que es análisis ante una situación en estudio y es por ello que en ocasiones existen impedimentos que hacen que a la final se tenga que hacer doble trabajo o tener que estar por mucho tiempo tratando de buscarle una solución. De esta manera este proyecto de una u otra manera se enfoca en que nosotros como estudiantes desarrollemos una buena capacidad de poder analizar con facilidad problemas, utilizando técnicas que a la hora de diseñar sea lo más fácil y sencillo de hacer. Así el lenguaje gráfico UML, especificar y documentar cada una de las partes que comprende el desarrollo de software. Utilizando modelo de Clases diagrama de clases sirve para observar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenido.

Síntesis #1 EL INVENTARIO
En contabilidad los inventarios forma parte muy importante para contabilización de mercancías, ya que por lo general, el activo mayor en sus balances generales, y los gastos por inventarios, llamados costo de mercancías vendidas, son usualmente el gasto mayor en el estado de resultados. Generalmente en toda empresa, negocio comercial su mayor actividad es la compra y venta de bienes o servicios; es aquí donde entra en juego el manejo del inventario. Este inventario constituye toda aquella mercancía que posee la empresa valorada al costo de adquisición, para la venta o actividades productivas ya que los empresarios necesitan de una constante información resumida y analizada sobre sus inventario. Esto implica el uso de otras cuentas como: El Inventario Inicial que es la cantidad de mercancía antes de ponerla a la venta, es decir, en la fecha que se comenzó el periodo contable. Compras son las mercancías compradas durante el periodo contable con el objetivo de volver a venderlas con fines de lucro. Devoluciones en compra, es la cuenta donde se devuelve la mercancía que la empresa compra por cualquier motivo. Gastos de Compras: Esta cuenta es la que se tiene que pagar por la adquisición de productos. Ventas: cuenta que contabiliza la cantidad de mercancía vendida. Devoluciones en Venta: devoluciones realizadas por los clientes a la empresa. Mercancías en Tránsito: se dan cuando la empresa ha pagado una mercancía comprada en el exterior y no ha sido recibida. Mercancía en Consignación: es cuando la empresa adquiere mercancías sin pagar hasta que sea vendida. El Inventario Actual (Final) se realiza al finalizar el periodo contable y unido con el inventario inicial, con las compras y ventas netas del periodo se obtendrá las Ganancias o Pérdidas Brutas en Ventas de ese período. Sistemas de inventarios: es donde la empresa mantiene un registro continuo para cada artículo del inventario, que ayudan a crear estados financieros ya que se puede determinar las ganancias o pérdidas sin tener que contabilizar el inventario ya existente. En los registros de inventario perpetuo 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, reorganizan 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. En los asientos bajo el sistema 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. El registro al diario sería así: Ventas a crédito de $900,000 (costo $540,000): Cuentas por cobrar $900,000

Ingresos por ventas $900,000 Costo de mercancías vendidas $540,000 Inventario $540,000 El sistema de inventario periódico Es donde se registra y contabiliza los artículos a vender para saber el costo del inventario final, esta es la cifra de inventario que aparece en el Balance General. Se utiliza también para calcular el costo de las mercancías este sistema se hace efectivo si el propietario conoce su inventario o lo tiene en mente por si un cliente le solita un producto por cantidad este sin la necesidad de tener que recurrir a inventarios escritos le dé una respuesta rápida. 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 continúa llevando el saldo inicial que quedó al final del período anterior. Sin embargo, al final del período, la cuenta inventario debe ser actualizada en los Estados Financieros. 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. Para determinar el costo de los inventarios se utilizan métodos denominados de costeo de los cuales podemos mencionar: El costo unitario específico, se da si una empresa vende por ejemplo bicicletas ($60.00), o sea artículos que se pueden identificar individualmente se facilita sacar su costo unitario que este caso representaría $60.00 independientemente si se vende a mayor precio. El costo promedio ponderado, es en el cual se fijan los precios de los artículos a vender siempre y cuando sean de la misma clase, estos precios se realizan mediante la división del dinero que se desea obtener de una venta entre la cantidad de artículos a disposición y para saber la cantidad de dinero obtenido de la venta simplemente multiplicamos la cantidad de artículos vendidos por el precio unitario por ejemplo: se desea obtener $3.000 por la venta de 10.000 Lb. de arroz, esto implica que el precio unitario por cada libra es de $0.30 y si se venden 9.000 Lb. el costo total de venta es de $2.700. El costo de primera entrada, primera salida (PEPS), resulta porque en ocasiones hay diferencia entre el costo de la mercancía vendida con el costo final de venta, por eso se utiliza este método que consiste en ir contabilizan las ventas a medida se realizan, es decir las primeras ventas realizadas son las primeras en salir a la hora de hacer el inventario final. Costo de Últimas Entradas, Primeras Salidas (UEPS), es en el cual la última venta realizada reportada en el inventario final representaría primera mercancía vendida en el control de mercancías vendidas. Es importante mencionar el control Interno Sobre Inventarios, ya que se mencionado al principio es la clave del éxito para las empresas es por ello que se deben hacer inventarios cada cierto tiempo mínimo un año, tener buenos depósitos de mercancías para evitar robos o descomposición, evitar que cualquier funcionario tenga acceso a los inventarios entre otros, no tener en archivadores los inventarios ya contabilizados y observarlos cierto tiempo para no tener artículos innecesarios por ejemplo. http://www.monografias.com/trabajos10/inve/inve.shtml

Síntesis #2 DEFINICIÓN Y CLASIFICACIÓN DE INVENTARIOS
Un inventario representa la existencia de bienes muebles e inmuebles que tiene la empresa para comercializar, comprando y vendiendo o procesándolos primero antes de venderlos, en un período económico determinado. Clasificación de los inventarios: Inventario de Mercancías, lo constituyen todos aquellos bienes que le pertenecen a la empresa bien sea comercial o mercantil, básicamente se refiere a la mercancía que la empresa a comprado para la venta, además se pueden incluir la mercancía comprada que ha sido pagada y sin recibir, las mercancías pignoradas (aquellas que son propiedad de la empresa pero que han sido dadas a clientes como garantía. 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 (que no han sido procesados) con los que se elaboran los productos. 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.).

http://www.gestiopolis.com/recursos/experto/catsexp/pagans/fin/43/inventario.htm

Síntesis #3 MANEJO DE INVENTARIOS

Tipos de inventarios: Inventarios periódicos: son aquellos que hacen las empresas pequeñas y medianas porque que se les facilita su inventario ya que manejan pocos artículos y así controlan los gastos por separado para que no afecten su inventario, y al final estos gastos junto con el inventario físico da como resultado el estado de pérdidas y ganancias. Método de inventario periódico: se hace para mantener un orden en las diferentes cuentas manejadas por la empresa, por ejemplo las compras realizadas se anotan a una cuenta, y la mercancía vendida se registra en una cuenta por separado. Existen algunos mecanismos para hacer inventaros sin tener que realizar el conteo de artículos, estos mecanismos son: Método de la utilidad bruta: este método es utilizado por experiencias que la empresa ha tenido en relación a sus ganancias, porque el precio de venta de un articulo esta formado por el precio pagado por el articulo en la compra mas la ganancia que se desea obtener. Método de ventas al detalle: este método consiste en hacer los inventarios a un estimado, ya que hay empresas por ejemplo tiendas (almacenes de ropa dividida en departamentos) en las que se hacen estados financieros al finalizar el día, y por esta razón es que los inventarios se hacen prácticamente todos los días porque hacer inventarios físicos en ese tipo de negocios es una tarea muy ardua. Inventario continuo o Perpetuo: este método consiste en que una vez se haya registrado la mercancía en el inventario con su precio, cantidad para que cuando se realiza una venta se vaya restando de dicho inventario. Métodos de primeras entradas, primeras salidas (PEPS): es donde la empresa lleva un registro del costo de los artículos que se compran para poner a la venta, porque existen ocasiones que el inventario final de la venta de ciertos artículos es diferente al costo unitario de dichos artículos es por ello que se contabilizan las ventas a medida se realizan, es decir las primeras ventas realizadas son las primeras en salir a la hora de hacer el inventario final. Métodos de últimas entradas, primeras salidas (UEPS), es en el cual la última venta realizada reportada en el inventario final representaría primera mercancía vendida en el control de mercancías vendidas destacando que esto depende del costo los artículos comprados para la venta. Método de Costo de promedio ponderado: generalmente este método es utilizado para saber la cantidad de ingreso de una venta de x cantidades de productos y de paso el costo unitario de cada artículo por ejemplo Descripción Peluches Bicicletas Cantidad total Unidades de artículos 100 500 600 Costo del total de venta 600.00 3,500.00 4,100

600 es el valor de todos los artículos a vender 4,100 es el costo de la venta

El costo ponderado se obtiene multiplicando la cantidad total de artículos a vender por el coto total de la venta (600*4,100=2460). Método de promedio simple, es un método poco usado, pero consiste en calcular normalmente un promedio solo que este caso se suma todos los costos de los artículos entre las cantidades de artículos, y precisamente no es utilizado porque solo muestra promedios. Método de promedio móvil, es donde cada vez que entra en el almacén un lote de mercancía, el costo unitario del saldo resultante, debe ser recalculado para evitar anomalías a la hora de hacer inventarios, la mercancía entrante es contabilizada en un solo bloque sin estarla separando por artículos diferentes. El costeo de las unidades que van saliendo, se hace en base al costo promedio calculado en saldo inmediato anterior. Es importante mencionar algunas bases legales que se deben tener en cuenta en los inventarios. Base legal: Artículos del código de comercio y de la ley de impuestos sobre la renta relacionados con la contabilidad mercantil. Artículo 32: todo comerciante debe llevar en idioma castellano su contabilidad, la cual comprenderá, obligatoriamente, el Libro Diario, el Libro Mayor y el de Inventarios. Artículo 33: el Libro Diario y el de Inventarios deben ser notificados ante un tribunal o notario para que tenga validez. Artículo 34: en el Libro Diario se especificará la mercancía vendida incluyendo a quien se le vendió para evidenciar las negociaciones realizadas diariamente. Artículo 35: todo comerciante, deberá rendir cuentas de sus bienes para que después no los vincule con los de los de la empresa. El inventario debe cerrarse con el balance y la cuenta de ganancias y pérdidas, para ver si valió la pena la inversión en el negocio. Artículo 38. - Los libros llevados que cumplan con orden los artículos anteriores con toda seguridad los comerciantes deben estar seguro de que se ha hecho un buen trabajo.

http://www.wikilearning.com/monografia/trabajo_de_inventario-tipos_de_inventario/12758

Síntesis #4 MODELO DE CLASES
Un diagrama de clases esta compuesto por los siguientes elementos: Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso. Elementos Clase Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). Atributos y Métodos: Atributos: características o propiedades que poseen las clases. Estas pueden ser de tres tipos: public : Indica que el atributo será accesible desde cualquier parte. Es visible para cualquier método o clase. private : Los atributos solo podrán ser accedidos mediante los métodos de la clase perteneciente. protected : Los atributos no podrán ser accedidos desde fuera de la clase, pero si por medio de los métodos de la clase y subclases que se deriven. Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características: public : Indica que el método será accesible desde cualquier parte. Es visible para cualquier método o clase. private : Los métodos solo podrán ser accedidos mediante los métodos de la clase perteneciente. protected : Los métodos no podrán ser accedidos desde fuera de la clase, pero si por medio de los métodos de la clase y subclases que se deriven. Relaciones entre Clases: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser: uno o muchos: 1..* (1..n) 0 o muchos: 0..* (0..n) número fijo: m (m denota el número). 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). Agregación: Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades: 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. Este tipo de relación es comunmente llamada Composición (el Objeto base se contruye a partir del objeto incluido, es decir, es "parte/todo"). 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. Este tipo de relación es comunmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).

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. Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente. 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. El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana . 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 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. El ejemplo más típico es el caso de un Diccionario en donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden ser genéricos. La genericidad puede venir dada de un Template (como en el caso de C++) o bien de alguna estructura predefinida (especialización a través de clases). http://www.dcc.uchile.cl∼psalinas/uml/modelo.html.

Síntesis #5 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. 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. Es un modo de indicar información en un formato libre, cuando la notación del diagrama en cuestión no nos permite expresar dicha información de manera adecuada. Dependencias La 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). Diagramas de Estructura Estatica 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 conceptualmente, mientras los primeros modelan elementos del dominio los segundos presentan los elementos de la solución software. 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. En el compartimento superior aparecen el nombre del objeto junto con el nombre de la clase subrayados, según la siguiente sintaxis: nombre_del_objeto: nombre_de_la_clase Puede representarse un objeto sin un nombre específico, entonces sólo aparece el nombre de la 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 continuación se verán los más importantes de entre dichos elementos gráficos. 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. 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). Roles 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. 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”. 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. Asociaciones N-Arias. 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. Se trata de un concepto de diseño, que indica que un objeto de la clase origen conoce al (los) objeto(s) de la clase destino, y por tanto puede llamar a alguna de sus operaciones. 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. 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. 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. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea.

Elementos Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso. Actores Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema. Se representa mediante una figura humana dibujada con palotes. 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. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema. 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. Para el caso de que queramos utilizar estos casos de uso más pequeños, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos: • Incluye (<>): Un caso de uso base incorpora explícitamente a otro caso de uso en un lugar especificado en dicho caso base. Al igual que en la herencia entre clases, el caso de uso hijo hereda las asociaciones y características del caso de uso padre. El caso de uso padre se trata de un caso de uso abstracto, que no está definido completamente. Este tipo de relación se utiliza mucho menos que las dos anteriores. Diagramas de Interacción En los diagramas de interacción se muestra un patrón de interacción entre objetos. Hay dos tipos de diagrama de interacción, ambos basados en la misma información, pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas de Colaboración. Diagrama de Secuencia Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interacción y los mensajes que intercambian ordenados según su secuencia en el tiempo. El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes en la interacción, sin un orden prefijado. Cada objeto o actor tiene una línea vertical, y los mensajes se representan mediante flechas entre los distintos objetos. 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). A diferencia de los Diagramas de Secuencia, los Diagramas de Colaboración muestran las relaciones entre los roles de los objetos. La secuencia de los mensajes y los flujos de ejecución concurrentes deben determinarse explícitamente mediante números de secuencia.

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. En él se indican qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que genera. En cuanto a la representación, un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos. Un diagrama de estados puede representar ciclos continuos o bien una vida finita, en la que hay un estado inicial de creación y un estado final de destrucción (finalización del caso de uso o destrucción del objeto). El estado inicial se muestra como un círculo sólido y el estado final como un círculo sólido rodeado de otro círculo. En realidad, los estados inicial y final son pseudoestados, pues un objeto no puede “estar” en esos estados, pero nos sirven para saber cuáles son las transiciones inicial y final(es). Modelado Dinámico 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, en el que se puede ver el flujo de actividades que tienen lugar a lo largo del tiempo, así como las tareas concurrentes que pueden realizarse a la vez. El diagrama de actividades sirve para representar el sistema desde otra perspectiva, y de este modo complementa a los anteriores diagramas vistos. 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. Contenido del diagrama de actividades Básicamente un diagrama de actividades contiene: • Estados de actividad • Estados de acción • Transiciones • Objetos Estados de actividad y estados de acción 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” 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.

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. 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, por una línea horizontal ancha. 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. modelado Físico De Un Sistema OO 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.” Interfaces tanto los servicios propio de una clase como los de un componente, se especifican a través de una Interfaz. Por ejemplo, todas las facilidades más conocidas de los sistemas operativos, basados en componentes (COM+, CORBA, etc.), utilizan las interfaces como lazo de unión entre unos componentes y otros. Tipos de componentes Existen básicamente tres tipos de componentes: Componentes de despliegue: componentes necesarios y suficientes para formar un sistema ejecutable, como pueden ser las bibliotecas dinámicas (DLLs) y ejecutables (EXEs). Componentes producto del trabajo: estos componentes son básicamente productos que quedan al final del proceso de desarrollo. Consisten en cosas como archivos de código fuente y de datos a partir de los cuales se crean los componentes de despliegue. Componentes de ejecución: son componentes que se crean como consecuencia de un sistema en ejecución. Es el caso de un objeto COM+ que se instancia a partir de una DLL. Organización de componentes Los componentes se pueden agrupar en paquetes de la misma forma que se organizan las clases. Además se pueden especificar entre ellos relaciones de dependencia, generalización, asociación (incluyendo agregación), y realización. Estereotipos de componentes: UML define cinco estereotipos estándar que se aplican a los componentes: executable Componente que se puede ejecutar en un nodo. library Biblioteca de objetos estática o dinámica. table Componentes que representa una tabla de una base de datos.

file Componente que representa un documento que contiene código fuente o datos. document Componente que representa un documento. UML no especifica iconos predefinidos para estos estereotipos. Nodos Al igual que los componentes los nodos pertenecen al mundo material. 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 representa normalmente un procesador o un dispositivo sobre el que se pueden desplegar los componentes. Un nodo debe tener un nombre asignado que lo distinga del resto de nodos. Nodos y componentes En muchos aspectos los nodos y los componentes tienen características parecidas. Vamos a ver con más detalle cuales son los parecidos y las diferencias entre los componentes y los nodos. Diagramas de Componentes Un diagrama de componentes muestra la organización y las dependencias entre un conjunto de componentes. Para todo sistema OO se han de construir una serie de diagramas que modelan tanto la parte estática (diagrama de clases), como dinámica (diagramas de secuencia, colaboración, estados y de actividades), pero llegado el momento todo esto se debe materializar en un sistema implementado que utilizará partes ya implementadas de otros sistemas, todo esto es lo que pretendemos modelar con los diagramas de componentes. Algunos conceptos Un diagrama de componentes muestra un conjunto de componentes y sus relaciones de manera gráfica a través del uso de nodos y arcos entre estos. Normalmente los diagramas de componentes contienen: • Componentes • Interfaces • Relaciones de dependencia, generalización, asociaciones y realización. • Paquetes o subsistemas • Instancias de algunas clases Visto de otro modo un diagrama de componentes puede ser un tipo especial de diagrama de clases que se centra en los componentes físicos del sistema. 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. Gráficamente un paquete viene representado como se indica en la Figura 34. Identificación de Paquetes Vamos a definir una serie de reglas que nos pueden ser de utilidad a la hora de agrupar los diferentes elementos en 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. 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. En este apartado se va a presentar 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. - 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. De ellas, la fase de Construir es la que va a consumir la mayor parte del esfuerzo y del tiempo en un proyecto de desarrollo. Para llevarla a cabo se va adoptar un enfoque iterativo, tomando en cada iteración un subconjunto de los requisitos (agrupados según casos de uso) y llevándolo a través del diseño de alto y bajo nivel hasta la implementación y pruebas, tal y como se muestra en la Figura 36. El sistema va creciendo incrementalmente en cada ciclo. Con esta aproximación se consigue disminuir el grado de complejidad que se trata en cada ciclo, y se tiene pronto en el proceso una parte del sistema funcionando que se puede contrastar con el usuario/cliente. 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 independiente del paradigma empleado posteriormente. IV.2.1 Actividades Las actividades de esta fase son las siguientes: • Definir el Plan-Borrador. • Crear el Informe de Investigación Preliminar. • Definir los Requisitos. • Registrar Términos en el Glosario. (continuado en posteriores fases) • Implementar un Prototipo. (opcional) • Definir Casos de Uso (de alto nivel y esenciales).

• Definir el Modelo Conceptual-Borrador. (puede retrasarse hasta una fase posterior) • Definir la Arquitectura del Sistema-Borrador. (puede retrasarse hasta una fase posterior) • Refinar el Plan. El orden no es estricto, lo normal es que las distintas actividades se solapen en el tiempo. Esto sucede también en las actividades de las fases de diseño, que se verán más adelante. De estas actividades no se va a entrar en las que corresponden al campo de la planificación de proyectos software, como las correspondientes a creación de planes e informes preliminares. IV.2.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. IV.2.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. Nótese que UML no define un formato para describir un caso de uso. Tan sólo define la manera de representar la relación entre actores y casos de uso en un diagrama: El Diagrama de Casos de Uso, definido en la página 9. Sin embargo, un caso de uso individual no es un diagrama, es un documento de texto 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. En un caso de uso descrito a alto nivel la descripción es muy general, normalmente se condensa en dos o tres frases. Es útil para comprender el ámbito y el grado de complejidad del sistema. 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 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.

Como guía para la identificación inicial de casos de uso hay dos métodos: a) Basado en Actores 1. Identificar los actores relacionados con el sistema y/o la organización. 2. Para cada actor, identificar los procesos que inicia o en los que participa. b) Basado en Eventos 1. Identificar los eventos externos a los que el sistema va a tener que responder. 2. Relacionar los eventos con actores y casos de uso. Identificación de los Límites del Sistema En la descripción de un caso de uso se hace referencia en todo momento al “sistema”. Para que los casos de uso tengan un significado completo es necesario que el sistema esté definido con precisión. 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. 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: Representan los procesos principales, los más comunes, como Realizar Reintegro en el caso del cajero automático. • Secundarios: Representan casos de uso menores, que van a necesitarse raramente, tales como Añadir Nueva Operación. • Opcionales: Representan procesos que pueden no ser abordados en el presente proyecto. b) Según el Grado de Compromiso con el Diseño En las descripciones que se han visto anteriormente no se han hecho apenas compromisos con la solución, se han descrito los casos de uso a un nivel abstracto, independiente de la tecnología y de la implementación. Un caso de uso definido a nivel abstracto se denomina esencial. Los casos de uso definidos a alto nivel son siempre esenciales por naturaleza, debido a su brevedad y abstracción. En principio, los casos de uso reales deberían ser creados en la fase de Diseño de Bajo Nivel y no antes. Sin embargo, en algunos proyectos se plantea la definición de interfaces en fases tempranas del ciclo de desarrollo, en base a que son parte del contrato. En este caso se pueden definir algunos o todos los casos de uso reales, a pesar de que suponen tomar decisiones de diseño muy pronto en el ciclo de vida. 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 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. Se asigna una versión simplificada cuando el caso de uso completo es demasiado complejo para ser tratado en un solo ciclo. 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. Inicialmente se desarrolla una versión simplificada, que se va completando en cada ciclo de desarrollo para satisfacer las necesidades de inicialización de los casos de uso que se tratan en dicho ciclo. Así se tiene un sistema en cada ciclo de desarrollo que puede funcionar.

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. Cuando el ciclo de desarrollo no es el primero, antes de la fase de Diseño de Alto Nivel hay una serie de actividades de planificación. Estas actividades consisten en actualizar los modelos que se tengan según lo que se haya implementado, pues siempre se producen desviaciones entre lo que se ha analizado y diseñado y lo que finalmente se construye. Una vez se tienen los modelos acordes con lo implementado se empieza el nuevo ciclo de desarrollo con la fase de Diseño de Alto Nivel. En esta fase se trabaja con los modelos de Diseño de Alto Nivel construidos en la fase anterior, ampliándolos con los conceptos correspondientes a los casos de uso que se traten en el ciclo de desarrollo actual. 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. En el Modelo Conceptual se tiene una representación de conceptos del mundo real, no de componentes software. 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. Creación del Modelo Conceptual Para crear el Modelo Conceptual se siguen los siguientes pasos: 1. Hacer una lista de conceptos candidato y una 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. 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. Se incluyen en el modelo las asociaciones siguientes: • Asociaciones para las que el conocimiento de la relación necesita mantenerse por un cierto período de tiempo (asociaciones “necesita-conocer”). 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. Incluso cuando un valor es de un tipo simple es más conveniente representarlo como concepto en las siguientes ocasiones: • Se compone de distintas secciones. Por ejemplo: un número de teléfono, el nombre de una persona, etc. • Tiene operaciones asociadas, tales como validación. Ejemplo: NIF. • Tiene otros atributos. Por ejemplo un precio de oferta puede tener fecha de fin.

• Es una cantidad con una unidad. Ejemplo: El precio, que puede estar en pesetas o en euros. Una vez definidos los atributos se tiene ya un Modelo Conceptual. Este modelo no es un modelo definitivo, pues a lo largo del desarrollo se va refinando según se le añaden conceptos que se habían pasado por alto. 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. 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 . En él se muestra para un escenario particular de un caso de uso los eventos que los actores generan, su orden, y los eventos que se intercambian entre sistemas. Construcción de un Diagrama de Secuencia del Sistema Para construir un Diagrama de Secuencia del Sistema para el curso típico de eventos de un caso de uso, se siguen los siguientes pasos: 1. Representar el sistema como un objeto con una línea debajo. 2. Identificar los actores que directamente operan con el sistema, y dibujar una línea para cada uno de ellos. 3. Partiendo del texto del curso típico de eventos del caso de uso, identificar los eventos (externos) del sistema que cada actor genera y representarlos en el diagrama. 4. Opcionalmente, incluir el texto del caso de uso en el margen del diagrama. Los eventos del sistema deberían expresarse en base a la noción de operación que representan, en vez de en base a la interfaz particular. Por ejemplo, se prefiere “finalizarOperación” a “presionadaTeclaEnter”, porque captura la finalidad de la operación sin realizar compromisos en cuanto a la interfaz usada. 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. Tiene una redacción en estilo declarativo, enfatizando en el qué más que en el cómo. Lo más común es expresar los contratos en forma de pre- y post-condiciones en torno a cambios de estado. Se puede escribir un contrato para un método individual de una clase software, o para una operación del sistema completa. En este punto se verá únicamente éste último caso. Un Contrato de Operación del Sistema describe cambios en el estado del sistema cuando una operación del sistema es invocada. Construcción de un Contrato Los pasos a seguir para construir un contrato son los siguientes: 1. Identificar las operaciones del sistema a partir de los Diagramas de Secuencia del Sistema. 2. Para cada operación del sistema construir un contrato. El uso de Diagramas de Estados es opcional. Tan solo los usaremos cuando consideremos que nos ayudan a expresar mejor el comportamiento del elemento descrito. Fase de construcción: diseño d 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 (clases y objetos) y cómo colaboran entre sí para realizar las funciones que se piden al sistema, según éstas se definieron en los contratos de operaciones del sistema. 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. Un objeto debe conocer a otro para poder llamar a uno de sus métodos, se dice entonces que el primer objeto tiene “visibilidad” sobre el segundo. La visibilidad más directa es por medio de atributo, cuando hay una asociación entre ambas clases y se puede navegar de la primera a la segunda (un atributo de la primera es un puntero a un objeto de la segunda). Hay otros tres tipos de visibilidad que hay que representar en el diagrama de clases mediante relaciones de dependencia: Parámetro: Cuando a un método de una clase se le pasa como parámetro un objeto de otra clase, se dice que la primera tiene visibilidad de parámetro sobre la segunda. La relación de dependencia entre ambas clases se etiqueta con el estereotipo <> (<> en inglés). - Local: Cuando en un método de una clase se define una variable local que es un objeto de otra clase, se dice que la primera tiene visibilidad local sobre la segunda. La relación de dependencia entre ambas clases se etiqueta con el estereotipo <>. - Global: Cuando hay una variable global en el sistema, instancia de una clase A, y un método de una clase B llama a un método de A, se dice que la clase B tiene visibilidad global sobre la clase A. La relación de dependencia entre ambas clases se etiqueta con el estereotipo <>. Construcción de un Diagrama de Clases de Diseño Normalmente se tiene una idea de un Diagrama de Clases, con una asignación de responsabilidades inicial. En caso de que no se tenga dicho Diagrama de Clases Borrador, puede seguirse la siguiente estrategia: 1. Identificar todas las clases participantes en la solución software. Esto se lleva a cabo analizando los Diagramas de Interacción. 2. Representarlas en un diagrama de clases. 2. Duplicar los atributos que aparezcan en los conceptos asociados del Modelo Conceptual. 4. Añadir los métodos, según aparecen en los Diagramas de Interacción. 5. Añadir información de tipo a los atributos y métodos. 6. Añadir las asociaciones necesarias para soportar la visibilidad de atributos requerida. 7. Añadir flechas de navegabilidad a las asociaciones para indicar la dirección de visibilidad de los atributos. 8. Añadir relaciones de dependencia para indicar visibilidad no correspondiente a atributos. Algunos de estos pasos se van realizando según se vayan completando los Diagramas de Interacción correspondientes. No existe precedencia entre la realización del Diagrama
-

de Clases de Diseño y los Diagramas de Interacción. Ambos tipos de diagramas se realizan en paralelo, y unas veces se trabaja primero más en el de clases y otras veces se trabaja primero más en los de interacción. IV.4.4.3 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. Como se vio en la parte II, se representa en UML mediante una flecha. Las asociaciones que aparezcan en el Diagrama de Clases deben cumplir una función, deben ser necesarias, si no es así deben eliminarse. Las situaciones más comunes en las que parece que se necesita definir una asociación con navegabilidad de A a B son: • A envía un mensaje a B. • A crea una instancia B. • A necesita mantener una conexión con B. 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. Otros Aspectos en el Diseño del Sistema En los puntos anteriores se ha hablado de decisiones de diseño a un nivel de granularidad fina, con las clases y objetos como unidades de decisión. 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. Sí hay que tener en cuenta que las posibles divisiones en subsistemas tienen que hacerse en base a las clases definidas en el Diagrama de Clases del Diseño. Fases de implementación de 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. Una vez se tiene una versión estable se pasa al siguiente ciclo de desarrollo para incrementar el sistema con los casos de uso asignados a tal ciclo. http://www.clikear.com/manuales/uml/

SÍNTESIS #6 TUTORIAL DE UML
Clase Es la unidad básica que encapsula toda la información de un Objeto. A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). En UML, una clase es representada por un rectángulo que posee tres divisiones: <Nombre Clase> <Atributos> <Operaciones o Métodos> En donde: Superior: Contiene el nombre de la Clase Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public). Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public). Atributos: Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son: public : Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados. private : Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar). protected : Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia). Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características: public : Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible 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 accesar). protected : Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven. Relaciones entre Clases: Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes). 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) Agregación: Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación,

tenemos dos posibilidades: 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. Este tipo de relación es comunmente llamada Composición (el Objeto base se contruye a partir del objeto incluido, es decir, es "parte/todo"). 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. Este tipo de relación es comunmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento). En donde se destaca que: Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias). Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados. La composición (por Valor) se destaca por un rombo relleno. La agregación (por Referencia) se destaca por un rombo transparente. La flecha en este tipo de relación indica la navegabilidad del objeto refereniado. Cuando no existe este tipo de particularidad la flecha se elimina. 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. Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente. 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. El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el objeto Aplicacion): 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 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. El ejemplo más típico es el caso de un Diccionario en donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden ser genéricos. La genericidad puede venir dada de un Template (como en el caso de C++) o bien de alguna estructura predefinida (especialización a través de clases). Diagrama de Interacción Elementos Objeto/Actor: El rectángulo representa una instancia de un Objeto en particular, y la línea punteada representa las llamadas a métodos del objeto. Mensaje a Otro Objeto:

Se representa por una flecha entre un objeto y otro, representa la llamada de un método (operación) de un objeto en particular. Mensaje al Mismo Objeto: No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a métodos desde el mismo objeto en estudio. Casos de Uso (Use Case) Elementos Actor: Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema. Caso de Uso: Es una operación / tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso. Relaciones: Asociación Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple. Dependencia o Instanciación Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada. Generalización Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>). Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores). extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características). uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica. De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar. http://www.esnips.com/doc/5ae972fd-837f-4ab4-a3c0-e5a575567699/Tutorial-deUML/?widget=documentIcon

GLOSARIO DEL TÉRMINO DEL DOMINIO
1- ) Contabilidad: Técnica que establece las normas y procedimientos para registrar, cuantificar, analizar e interpretar los hechos económicos que afectan el patrimonio de cualquier organización económica o entidad, proporcionando información útil, confiable, oportuna, y veraz cuyo fin es lograr el control financiero. 2- ) Gasto: En general se entiende por gasto al sacrificio económico para la adquisición de un bien o servicio, derivado de la operación normal de la organización, y que no se espera que pueda generar ingresos en el futuro. A diferencia de los gastos, los costos, por ejemplo de compra de materias primas, generarán probablemente un ingreso en el futuro al ser transformados y vendidos como producto terminado. 3- ) Costos: Se denomina costo al valor económico que representa la fabricación de cualquier componente o producto, o la prestación de cualquier servicio. Conociendo el costo de un producto o servicio se puede determinar el precio de venta al público de dicho producto o servicio, ya que Precio de venta=costo de fabricación+ganancia a obtener.

4- ) Activo mayor: es el documento que incorporan la titularidad de derechos sobre un bien fácilmente convertible en dinero, el cual es negociado en mercados de capitales. 5- ) Estado de resultado: es el estado que suministra información de las causas que generaron el resultado atribuible al período sea bien este un resultado de ganancia o pérdida. 6- ) Periodo contable: es el espacio de tiempo en el que deben rendirse y registrarse todos los resultados de la empresa, generalmente es un ejercicio de doce meses (1 año) en el cual deben acumularse los ingresos y los gastos, independientemente de la fecha en que se paguen 7- ) Balance general: es el estado financiero que, a una fecha determinada, muestra contablemente los activos de una empresa (lo que la empresa posee); sus pasivos (lo que la empresa debe) y la diferencia (su patrimonio neto). 8- ) Estado financiero: es el producto final que se refiere al Balance General y el estado de Pérdidas y Ganancias de una empresa, en el cual se resumen la situación económica y financiera de la empresa y es útil para los que tengan intereses en las empresas como los accionistas, acreedores o propietarios. 9- ) Métodos: Proceso o camino sistemático establecido para realizar una tarea o trabajo con el fin de alcanzar un objetivo predeterminado.

10- ) Herencia: es el mecanismo que permite derivar características de una clase a otra y así extender sus funcionalidades. 11- ) Caso de uso: es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. 12- ) Diagramas de interacción: explican gráficamente como los objetos interactúan a través de mensajes para realizar tareas. 13- ) Diagramas de actividades: diagrama nos servirá para definir los procesos de negocio, que ha de contemplar nuestro sistema de información. Los diagramas de actividades forman parte del modelado del negocio. Al realizar el diagrama de actividades podemos ver de una forma clara todas actividades y su flujo lógico 14- ) Interfaz: s un conjunto de operaciones y/o propiedades que permiten a un objeto comportarse de cierta manera, por lo que define los requerimientos mínimos del objeto. 15- ) Visibilidad: es un elemento necesario pues de otro modo no podrá darse soporte a la interacción de los mensajes.

ENCUESTA DE INVENTARIO REALIZADA A JOSÉ MORENO

En que consiste inventario: en la revisión de los activos, acciones, materiales o propiedades que tiene una empresa o negocio. Su propósito es controlar las existencias reales que se tienen en el Almacén General de los artículos y materiales de consumo para obtener un inventario físico apegado a la realidad. Políticas de operación El Jefe del Departamento de Recursos Materiales y Servicios Generales podrá llevar a cabo sin previo aviso inventarios físicos de artículos y materiales de consumo en el almacén general. El Departamento de Recursos Materiales y Servicios Generales deberá efectuar dos inventarios programados durante el año con el objeto de verificar físicamente los artículos en existencia. Un inventario se puede realizar por diferentes personas, no requiere de un conocimiento basto, solo con manejar los conceptos básicos de contabilidad, Realización de un inventario en una empresa pública El inventario de una institución pública se hace de la siguiente manera: Se puede hacer para conocer o revisar tu mercancía o simplemente para mantener una regulación de tu almacén o mantenerlo en regla, este tipo de inventario se puede dar mensualmente, trimestralmente o como disponga el almacenista . La otra forma es la del revisado por parte de un empleado de la institución en este caso un auditor de designado por la institución y se da de la siguiente forma: El auditor va ha el departamento de kardex (El kardex es un sistema de registro y control de almacén tradicional) y toma la información de el tarjetário que lleva el kardista; este inventario puede ser total o selectivo. Anota en el libro o libreta cada producto y código y luego procede al almacén donde se encuentra la mercancía descrita anteriormente. Asistente: este se encarga de contar la mercancía, revisa el código, fecha de vencimiento, lote y se lo dicta al auditor posteriormente compara el registro anotado en kardex versus el deposito. Puede haber faltantes y sobrantes, se hacen las notas para cuadrar el deposito y así después de firma las actas termina el inventario. Semanas después el auditor hace un informe de las posibles recomendaciones y sanciones

DESCRIPCIÓN DEL PROCEDIMIENTO
SECUENCIA DE ETAPAS 1. Realiza un inventario mensual de las mercancías existentes en el almacén general y las anota en las hojas de existencias. 2. Solicita personal del Departamento de Recursos Financieros para hacer inventario. 3. Designa al personal que asistirá a hacer el inventario en el Almacén General. 4. Acude al Almacén General con el kardex, las hojas de existencias y acompañado de personal del Departamento de Recursos Financieros a realizar un conteo de los artículos ahí almacenados. ACTIVIDAD 1.1 Realiza el conteo mensual de las mercancías existentes en el almacén general. 1.2 Anota la cantidad resultante en su hoja de existencias en la columna Físico. 1.3 Turna las hojas de existencias al Departamento de Recursos Materiales y Servicios Generales. Departamento de 2.1 Recibe las hojas de existencia. Recursos Materiales y 2.2 Solicita al Departamento de Recursos Servicios Generales Financieros designe personal para que lo acompañe al Almacén General a hacer inventario. Departamento de 3.1 Designa a una o dos personas para que Recursos Financieros acompañen al Jefe del Departamento de Recursos Materiales al Almacén General a hacer inventario. Departamento de 4.1 Acude al Almacén General acompañado Recursos Materiales y de personal del Departamento de Recursos Servicios Generales Financieros a realizar un conteo de los artículos.. 4.2 Compara el resultado del conteo con lo anotado en el Kardex y en las hojas de existencias. ¿Existen diferencias? NO Termina el procedimiento. SI Procede a aclararlas con el Encargado del Almacén y los registros en kardex; si persisten las diferencias se lleva a cabo un segundo conteo. RESPONSABLE Almacén General

5. Elabora Acta Departamento de Administrativa si 5.1 Determina que son faltantes si las Recursos Materiales y persisten faltantes. diferencias no son aclaradas después del Servicios Generales segundo conteo. 5.2 Elabora Acta Administrativa describiendo el hecho según corresponda.

REFLEXIONES INDIVIDUALES
Ángel Aguilar Fue una labor bastante extenuante y sofocada ya que tuvimos serios inconvenientes con otras asignaturas lo cual nos dificultó la realización exitosa de este proyecto, pero en conjunto trabajamos para terminar el proyecto aunque un poco tarde. La parte más difícil fue sobre el análisis y diseño UML del sistema porque este tipo de diseño era totalmente desconocido para nosotros pero siempre se pudo aprender sobre los sistemas de diseño. La metodología empleada para lograr los objetivos de este trabajo fue la de estudiar los tutoriales presentados por el facilitador para comprender el problema de estudio. Dentro de nuevos conocimientos logrados podemos mencionar aspectos relativamente importante de lenguaje UML y observar su funcionamiento, dentro de los conocimientos previos que fueron esenciales puedo expresar que fueron algo escasos ya que en mi caso tenemos problemas para hacer análisis buenos, la importancia obtenida en esta experiencia para nuestra formación profesional es que en la vida uno debe conocer un poco de todas las áreas por la informática precisamente esta relacionada con muchos dominios independientes a ella y en cuanto utilidad tiene el trabajo realizado puedo reiterar que se realiza para empresas y facilitar un poco en arduo trabajo a las personas que se dedican a hacer inventarios. Norbeto Delgado Bueno la labor fue un poco atenuante debido a que en realidad no sabíamos que hacer o mas bien como hacer este trabajo que para mi en lo personal pensé que era algo de otro mundo debido al implementación del lenguaje que ahora conozco, que es UML, y como nunca habíamos estudiado este lenguaje me pareció que hacer este trabajo sin saber nada de cómo se implementaba este lenguaje iba a ser muy difícil llevarlo a cabo. La parte mas difícil fue la de crear un diagrama UML que no sabia a ciencia cierta como se hacia y además implementarlo en el sistema de inventario que se había establecido. Los conocimientos que adquirí fueron la creación de un programa orientado a objetos con un diseño UML, también como se hace un inventario y todo lo referente a lo que es el lenguaje UML como es en general su forma de usarse. Los conocimientos previos fueron primero que todo lo que es la programa orientado a objetos, como se realizaba un inventario,. La importancia es que te permite ampliar tus conocimientos, y también nunca se sabe cuando necesitas realizar un inventario en tu vida de lo que menos te imaginas y con el conocimiento que se creo en esta experiencia te permitirá entra en un campo mas de los que se abren con la informática y con ambos campos al unirse e comprobado que se pueden generar una buena inversión para el que pueda manejar ambos ambientes. Muchas ya que permite implementar un sistema mas avanzado y asta mas eficaz para lo que es la contabilidad de una empresa o negocio y la implementación de mejores sistemas para la generación de trabajos.

Fernando Villarreal La labor de los integrantes fue un poco difícil ya que nuestro grupo era un poco ignorante ante este trabajo mucho mas en lo que es el lenguaje UML. La parte mas difícil fue la interpretación de el sistema UML y lo que fue entender lo que se tenía que hacer. La metodología fue un poco baga ya que no sabíamos manejar lo que fue en si el lenguaje UML. Los conocimientos fueron que no siempre hay una sola forma de hacer las cosas, que siempre se aprende algo innovador que te permite avanzar en nuestro futuro de informático. Lo mas necesario fue lo que es el conocimiento de lo que es la programación orientada a objetos ya que a partir de hay comenzó todo nuestro informe. La experiencia es algo como un poco nuevo para nosotros ya que no habíamos incursionado tanto en lo que es UNL y también en lo que es un inventario y todo lo que constituye una empresa. Es muy importante ya que es algo que no considerábamos y por tanto nos perdíamos conocimientos que son necesarios para la implementación de trabajos que nos puedan veneficiar en un futuro cercano.

CONCLUSIÓN

Un trabajo que ciertamente fue bastante tedioso pero que vale la pena, por supuesto porque podemos decir algunos aspectos importantes como lo siguiente, los inventarios son herramientas útiles para las empresas y que estos en fusión la programación orientada a objetos tienen buenos resultados como la creación de programas para facilitar la contabilidad. Con 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. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades claramente estos diagrama puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o el de Casos de Uso (son diferentes). Los componentes principal 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. El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso).

Sign up to vote on this title
UsefulNot useful