6.6 DISEÑO. [Proceso]

Save this PDF as:
 WORD  PNG  TXT  JPG

Tamaño: px
Comenzar la demostración a partir de la página:

Download "6.6 DISEÑO. [Proceso]"

Transcripción

1 6.6 DISEÑO. [Proceso] Durante un Ciclo de Desarrollo iterativo es posible pasar a la Fase de Diseño una vez completada la documentación de la fase de Análisis. Durante esta etapa se desarrolla una solución lógica basada en el paradigma orientado a objetos. La parte central de esta solución se basa en la cr4eación de Diagramas de Interacción. Estos diagramas muestran la forma en que los objetos se comunican y de esta forma cumplen con los requerimientos establecidos. Una vez terminados los Diagramas de Interacción propuestas para el ciclo de desarrollo actual, se procede al diseño de los Diagramas de Clases, los cuales contienen las clases (interfaces) que serán implementadas mediante software Describiendo Casos de Uso Reales. Los casos de uso reales presentan un diseño concreto, la forma en que un Caso de Uso deberá ser realizado. La definición de Casos de Uso Reales es la primera actividad a realizar durante la fase de diseño en el ciclo de desarrollo actual. La creación de los Casos de Uso Reales esta basada en la definición previa de los Casos de Uso esenciales relacionados. Casos de Uso: Expandido y Esencial Casos de Uso: Real Caso de Uso Interacción Modelo Conceptual Glosario Clases Diagrama Secuencia Sistema Contratos de del Arquitectura de Paquetes Diagrama Estado de Base de Datos Figura # 8, Dependencias, Fase de Diseño. Creación de Caso de Uso Reales Un Caso de Uso Real describe el diseño real del caso de uso en términos de entradas y salidas concretas pensando en la tecnología disponible para su implementación.. En ocasiones a manera de ejemplificar pueden ser involucradas interfaces graficas a manera de prototipos, no es 62

2 necesario implementarlas, sin embargo son una alternativa para presentar detalles de la implementación, durante el diseño. A continuación se muestra el Caso de Uso de la Facturación Versión, en donde se ha agregado algunas textos para clarificar detalles del curso de eventos. NOMBRE: Facturación Versión. Caso de Uso: Facturación Versión. Actores: Propósito: Tipo: Descripción: Referencias Cruzadas: Cliente (iniciador), Vendedor. Generar un documento con los datos del cliente, datos y precio de los productos y el total de la venta. Llamado Factura. Primario y esencial. El Vendedor introduce la clave del producto, el número de productos, la clave del cliente. se calcula el subtotal por producto y el total de la venta. R3, R4, R5, R6, R7 Curso de Eventos: Facturación Versión. No Acción del Actor No Respuesta del Sistema. Este caso de uso inicia cuando el Cliente llega a la terminal de Punto de Venta con los productos que desea adquirir. 2. Para cada artículo el vendedor introduce la clave del producto. 3. Busca en el archivo la clave del artículo y muestra su descripción y precio de lista. Se agrega a la lista de productos adquiridos. 5. Se calcula y muestra el total del importe por cada artículo. 7. Se calcula y despliega el total de la venta. 4. El vendedor teclea el número de artículos solicitados por el Cliente. 6. Una vez terminada la captura de todos los artículos. el vendedor indica fin de la venta. 8. El Vendedor introduce el número de cliente. 0. El Vendedor pide la confirmación de los datos al Cliente. El Vendedor manda a imprimir la Factura 2. Se imprime la Factura. 9. Busca en el archivo y despliega los datos del cliente. 63

3 6.6.2 Diseño de diagramas de interacción. Durante la etapa del diseño hay dos pasos importantes a dar: la asignación de responsabilidades y la creación de diagramas de interacción. Los Diagramas de Interacción ilustran la manera de cómo los objetos interactúan vía mensajes para llevar a cabo un tarea especifica. La creación de Diagramas de Interacción ocurre dentro de la fase de diseño durante el ciclo de desarrollo en cuestión. Su creación depende de haber trabajado previamente en los artifacs mostrados en la Figura # 9. Casos de Uso: Expandido y Esencial Casos de Uso: Real Caso de Uso Modelo Conceptual Glosario Interacción Clases Diagrama Secuencia Sistema Contratos de del Arquitectura de Paquetes Diagrama Estado de Base de Datos Figura 9, Dependencias Fase de Diseño. Creación de Interacción. Uno de los problemas mas comunes en la creación de proyectos utilizando la tecnología de objetos es valorar la creación de los diagramas de interacción, al cuidar el asignar responsabilidades y hacer que cada una de ellas y todas en conjunto cumplan con los requerimientos establecidos. Por lo que el asignar responsabilidades y diseñar objetos colaborativos es muy importante, entonces, una porcentaje considerable del trabajo en el proyecto deberá aplicarse a la fase del diseño de diagramas de interacción Responsabilidades y métodos. La Responsabilidad se define como un contrato u obligación de un tipo o clase. Las responsabilidades están relacionadas a las obligaciones de un objeto en términos de su comportamiento, siendo básicamente de 2 tipos: 64

4 . Responsabilidad de conocer. 2. Responsabilidad de hacer. La responsabilidad de conocimiento de un objeto incluye: Conocimiento acerca de encapsulamiento de datos privados. Conocimiento acerca de objetos relacionados. Conocimiento de cosas que puede dirigir o calcular. La responsabilidad de hacer de un objeto incluye: Hacer alguna cosa por él mismo. Inicializar acciones sobre otros objetos. Las responsabilidades se asignan a objetos durante la fase de diseño. Las responsabilidades relacionadas con el conocimiento son frecuentemente identificadas desde el modelo conceptual ya que en él se muestran atributos y asociaciones. La translación de responsabilidades en clases y métodos se ve influenciada por la granularidad de la responsabilidad. Una responsabilidad no es lo mismo que un método, los métodos son implementados para cumplir responsabilidades. Las responsabilidades se implementan usando métodos, los que actuan tanto sobre otros métodos como sobre objetos. La manera de implementar las responsabilidades (implementadas como métodos) es mediante la creación de los interacción, los cuales muestra las interacciones de los mensajes entre instancias (y clases) en el Modelo de Clase. El punto de partida para estas interacciones son las descripciones de las Post-condiciones de los contratos. El UML define dos conjuntos de diagramas de interacción, donde cualquiera de los dos expresan los mismos conceptos en cuanto a la interacción de los mensajes: Diagramas de Secuencia. Ilustran la interacción entre objetos, en una secuencia de tiempo, expresada en el eje vertical. Diagramas de Colaboración. Ilustran la interacción entre objetos, utilizando un formato de grafo o de red Patrones. En la tecnología e objetos, un Patrón es la descripción de un problema y su solución, la cual puede ser aplicada a un nuevo contexto. Existen patrones que brindan lineamientos de cómo asignar las responsabilidades a objetos en el contexto de categorías especificas de problemas Patrones: Principios Generales de Asignación de Responsabilidades (del inglés GRASP). Existen 5 categorías de patrones GRASP. Experto. Creador. Bajo acoplamiento. Alta Cohesión. Controlador. 65

5 PATRÓN: Experto. Asigna una responsabilidad al experto de la información --- La clase Solución: que tiene la información necesaria para cumplir con la responsabilidad Problema: Cuál es el principio básico por el cual las responsabilidades son asignadas en el Diseño Orientado. Un Modelo de Clase puede definir docenas de cientos de clases de software y una aplicación puede requerir cientos de miles de responsabilidades a ser cumplidas. Durante el Diseño Orientado a Objetos, cuando la interacción entre objetos es definida, ya se deben haber asignado las responsabilidades a las clases. Un sistema bien hecho, tiende a ser fácil de entender, mantener y extender, y existe la oportunidad del rehúso de los componentes en futuras aplicaciones. Discusión: Este patrón es el mas usado en la asignación de responsabilidades, el objeto hace cosas relacionadas con la información que tiene. También se pueden manejar Expertos parciales cuando se requiere información contenida en otras clases y objetos. Beneficios: Se mantiene el encapsulamiento, ya que los objetos utilizan su propia información. El comportamiento del sistema es distribuido a través de clases que cuentan con la información requerida PATRON: Creador Solución Asignar a la clase B la responsabilidad de crear una instancia de la clase A, si se cumple cualquiera de los siguientes puntos: B es una agregación del objeto A B contiene objetos del tipo A B actualiza instancias de objetos A B usa estrechamente objetos A B inicializa datos que van a ser pasados a A cuando es creado (entonces, B es un Experto con respecto a la creación de A). B es creador de A Si aplica mas de una opción, entonces, B deberá contener a, A. Problema: Quien deberá tener la responsabilidad para la creación de una instancia de alguna clase. La creación de objetos es una de las actividades mas comunes en un sistema orientado a objetos, consecuentemente es útil contar con principios para asignar responsabilidades de creación de instancias. Haciendo una buena asignación, el diseño tendrá bajo acoplamiento, incrementando la claridad, encapsulamiento y rehusabilidad. Discusión: Los lineamientos de creación asignan responsabilidades relacionadas con la creación de objetos, una actividad muy común en los sistemas orientados a objetos Agregación agrega parte, Contenedor contiene contenido, Actualizador actualiza graba. La actualización de información es una relación muy común entre clases en un diagrama de clases Beneficios: Bajo acoplamiento, implica menor dependencia en el mantenimiento y alta oportunidad de rehúso. 66

6 PATRON: Bajo Acoplamiento Solución Asigna responsabilidades, de tal forma que el acoplamiento permanezca bajo Problema: Cómo soportar baja dependencia e incrementar el rehúso. Una clase con alto acoplamiento, hace referencia a muchas otras clases, tales clases son indeseables, ocasionando los siguientes problemas: Cambios en las clases relacionadas propician cambios locales. Difíciles de entender para aislarlas. Difíciles de rehusar ya que su uso requiere la presencia adicional de las clases de las que depende. discusión: El bajo acoplamiento es un principio que se debe cuidar durante las decisiones de diseño, es un lineamiento que se debe considerar continuamente. Es un patrón de evaluación, aplicado por cualquier diseñador al avaluar cualquier decisión de diseño. En los lenguajes orientados a objetos una forma común de acoplamiento desde un Tipo_X a un Tipo_Y incluye: Tipo_X tiene un atributo (dato miembro o variable de instancia) que hace referencia a una instancia del Tipo_Y o al Tipo_Y en sí mismo. Tipo_X tiene un método él cual hace referencia a una instancia del Tipo_Y o Tipo_Y en sí mismo, por cualquier medio. Esto incluye a un parámetro o variable local del Tipo_Y o el objeto regresado desde un mensaje referenciando una instancia del Tipo_Y. Tipo_X es directa o indirectamente una subclase del tipo_y. Tipo_Y es una interfase, y Tipo_X implementa la interfase. El bajo acoplamiento soporta el diseño de clases que son mas independientes, lo que redice el impacto de cambios y propicia el rehúso, dando la oportunidad de una productividad mayor. El bajo acoplamiento puede no ser importante si no se piensa en la reutilización Una subclase esta fuertemente acoplada a su superclase. La decisión de derivar de una superclase deberá ser cuidadosamente considerada desde este punto de vista. Beneficios: No hay afectación por cambios en otros componentes. Simple para entender el aislamiento. Conveniente para rehúso. 67

7 PATRON: Alta Cohesión. Solución Asignar responsabilidades manteniendo alta cohesión. Problema: Cómo mantener la complejidad manejable. En términos de diseño orientado a objetos, la cohesión (o de manera mas específica, la cohesión funcional) es una medida de que tanto se ha enfocado la responsabilidad en una clase, así, una clase con una responsabilidad alta, y que no realiza un trajo abrumador, tiene una alta cohesión. Una clase con una baja cohesión hace muchas cosas irrelevantes o realiza mucho trabajo, tales clases son indeseables, ellas tienen los siguientes problemas: Difíciles de comprender. Difíciles de usar. Difíciles de mantener. Clases con baja cohesión representan un alto grado de abstracción o tienen responsabilidades que deberán ser delegadas a otras clases. discusión: Tanto el Bajo acoplamiento como la alta cohesión deberán ser principios que se deben tomar en cuenta en las decisiones de diseño, son lineamientos que se deben siempre considerar. Es un patrón de evaluación que el diseñador aplica mientras toma decisiones de diseño. Muy baja cohesión. Una clase es la responsable de muchas cosas en diferentes áreas de funcionalidad. Baja Cohesión. Una clase es la responsable de realizar un trabajo complejo en un área de funcionalidad. Alta Cohesión. Una clase tiene moderadas responsabilidades en un área funcional y colabora con otras clases para llevar a cabo otros trabajos. Moderada Cohesión. Una clase tiene moderada responsabilidad en varias áreas diferentes que están lógicamente relacionadas al concepto de la clase, pero no a otras. Beneficios: Se mejora la claridad y la compresión del diseño. Se simplifica el mantenimiento. Soporta con frecuencia también bajo acoplamiento. Una ganancia adicional con la relativamente alta funcionalidad agregada se incrementa el rehúso, ya que una clase con alta cohesión se puede usar para propósitos muy específicos. 68

8 PATRON: Controlador Solución Asignar la responsabilidad del manejo de los mensajes de eventos a una clase que represente: El sistema. El negocio o la organización. Alguna cosa del mundo real que es activo. Un manejador artificial de todos los eventos del sistema, de un caso de uso. Usar la misma clase controlador para todos los eventos del sistema en el mismo caso de uso. Problema: Quién deberá asumir la responsabilidad de manejar los eventos del sistema. Un evento del sistema es un evento del sistema de alto nivel generado por un actor externo; es un evento externo de entrada, son asociados con operaciones del sistema --- operaciones del sistema en respuesta a eventos del sistema Un Controlador no es un objeto de interfase de usuario responsable del manejo de los eventos del sistema. Un Controlador define los métodos para la operación del sistema. discusión: La mayoría de los sistemas reciben eventos externos, como la IU, de censores de señal, etc. Un defecto común en el diseño de controladores es asignarles muchas responsabilidades. Normalmente un controlador deberá delegar a otros objetos el trabajo que necesita realizar mientras coordina las actividades Beneficios: Incrementa el potencial para componentes reutilizables. Asegura que los procesos son manejados por objetos de la capa de dominio, no por objetos del de la capa de interfase.. La responsabilidad de un controlador técnicamente deberá ser manejada por un objeto de interfase, pero la implementación de tal diseño es que el código y lógica del programa se manejen como procesos del dominio. Conocimiento del estado del caso de uso. Ayuda a que las operaciones ocurran en una secuencia lógica o que se identifique el estado actual del caso de uso Responsabilidades y cartas CRC. Un dispositivo que puede ayudar a asignar responsabilidades e indicar colaboraciones con otros objetos son las Cartas CRC (Cartas de: Clase Responsabilidad Colaboración), éstas fueron diseñadas por Kent Beck y Ward Cunningham. Las cartas CRC son cartas de índice, una para cada clase, sobre las cuales se escriben brevemente las responsabilidades e cada clase y una lista de los objetos que colaboran para cumplir con la tarea asignada. Normalmente se analiza el rol jugado por cada clase o por un conjunto pequeño de clases. La asignación de responsabilidades y el desarrollo de los Diagramas de interacción es la etapa de creación mas significativa durante la etapa de diseño. 69

9 6.6.5 Como hacer un diagrama de interacción. Crear un diagrama por separado para cada operación del sistema que se encuentra en el ciclo de desarrollo actual. Para cada operación del sistema, haga un diagrama, utilizando el nombre de la operación como el mensaje de inicio. 2. Si el diagrama es demasiado complejo dividirlo en pequeños diagramas. 3. Usar del contrato: la sección de responsabilidades, post-condiciones y la descripción del caso de uso como un punto de inicio, diseñe un sistema de objetos que interactúen que cumplan con el trabajo encomendado Diagramas de iteración del Caso de Uso Facturación Versión [Caso de Estudio] Tomando como base el Secuencia del Sistema, y las operaciones encontradas, se deberán construir los siguientes diagramas de iteración:. Entra artículo. 2. Fin de venta. 3. Entra Cliente. Para cada evento del sistema crear un diagrama de interacción donde el mensaje de inicia sea el mensaje del evento del sistema. Usando las secciones de responsabilidades y post-condiciones de los contratos y los casos de uso como punto de partida, diseñar un sistema de objetos que interactúan para llevar a cabo una tarea.. Contrato: Entra Artículo. CONTRATO: entra_articulo() Nombre entra_artículo(numero : entero, cantidad : entero) Responsabilidad Tipo Referencia cruzada Notas Excepciones Salida Registrar la compra de un articulo, añadirlo a la venta total, desplegar precio de lista y su descripción. Cuando se introduce la cantidad de artículos despliega el precio total por artículo. Sistema. R4, R5, R6 Accesa el Catalogo de Productos. Envía un error si no existe el artículo. Muestra la descripción del artículo, su precio de lista y el importe total por artículo. 70

10 Pre-condición Es necesario conocer la clave del producto y la cantidad de productos solicitada por el Cliente. Post-condición Al introducir el primer artículo, se crea una nueva instancia de Venta. Se crea una asociación con el producto. Al introducir la cantidad de productos, se modifica el atributo Venta.cantidad. Definiendo un controlador. De acuerdo a los patrones es necesario definir el controlador. una opción es la Terminal de Punto de Venta TPV. No es un objeto del dominio, va a ser un objeto en el dominio del software. Puede representar el Sistema del Vivero. : entra_articulo(numero, cantidad) : TPV : Vendedor Figura # 20, Definir Controlador Si se considera el principio de separación Modelo Vista, no es responsabilidad de los objetos del dominio comunicarse con el usuario, por lo tanto, los procesos que indiquen una visualización de datos deberán ser ignorados. Lo que se requiere con respecto a la responsabilidad de mostrar información es que el dato sea conocido. Registrar una nueva venta. Al iniciar una nueva venta se debe crear una nueva instancia de Factura. Posteriormente se debe crear la asociación correspondiente. Analizando el Modelo conceptual y reflexionando sobre los objetos del dominio, TPV es el candidato para crear una nueva instancia de Factura. Analizando el modelo conceptual, es necesario también crear una colección de instancias (instancias de Venta) que mantengan información de la cantidad adquirida de cada producto. De esta forma TPV crea una instancia de factura y la factura crea una colección vacía de instancias de Venta. Creando una nueva instancia para Venta. Se creo una instancia de Venta. (creación de instancia) La venta se asoció con la Factura. (formación de asociación) Se modifica la cantidad. (modificación de atributo) 7

11 : entra_articulo(numero, cantidad) : TPV 2: crea() : Factura : Vendedor 3: crea_coleccion() Figura #2, Crear instancia de Factura y colección vacía de Venta : Venta Encontrando la especificación del producto. La instancia de Venta debe ser asociada con la Especificación del producto, él cual debe tener el número de la clave del producto, lo cual es necesario para obtener una Especificación de Producto. Es necesario primero pensar en quien es responsable de conocer la Especificación del producto en base a su número de clave. Usando el patrón Experto dice; que quien posea la información deberá ser el indicado de cumplir la responsabilidad. Analizando el Modelo Conceptual se ve que el indicado es el Catalogo de Productos, por lo que este concepto es un buen candidato para cumplir con la responsabilidad. Visibilidad hacia el Catalogo de Productos. Quién deberá enviar el mensaje de especificación a el Catalogo de Productos para preguntar por la Especificación del Producto?. Si se asume que las instancias de TPV y el Catalogo de Productos fueron creados durante el inicio del Caso de uso y que la conexión entre ellos es permanente y suponiendo que es posible para el TPV enviar el mensaje de especificación al Catalogo de Productos. Esto implica otro concepto en el Diseño Orientado : visibilidad. La Visibilidad es la habilidad de un objeto para ver o tener una referencia de otro objeto. Para que un objeto envie un mensaje a otro objeto debe teber visibilidad de él. Colaboración de entra artículo. Es necesario hacer una serie de reflexiones basadas en los patrones GRASP para conseguir el diseño del diagrama; El diseño de objetos que interactúan y la asignación de responsabilidades, requieren considerable tiempo de deliberación. Mensajes a multiobjetos. El mensaje busca() deberá localizar en la Especificación del Producto, aquel que coincida en el numero de producto. El mensaje crea() va a crear la colección vacía. El mensaje crea(cantidad) crea una instancia de Venta. El mensaje suma() agrega un elemento Venta a la colección. 72

12 : entra_articulo(numero, cantidad) 2: crea() : TPV : Factura : Vendedor 4: prod = especifica(numero) 6: suma_art( prod, cantidad) 3: crea_coleccion() : Cat_producto 7: crea(prod, cantidad) 5: prod = busca(numero) : Esp_Producto 8: suma(vi) : Venta Figura # 22, Colaboración, entra_articulo CONTRATO: Fin de Venta. Este contrato ocurre cuando el Vendedor selecciona fin de venta. CONTRATO: fin_venta() Nombre fin_venta( ) Responsabilidades Tipo Referencias cruzadas Notas Excepciones Salida Pre-condiciones Termina el proceso de captura de artículos, calcula el importe total de la venta. Sistema R7 Se muestra el importe total de la Venta. Post-condiciones! Se actualiza su numero (el cual es consecutivo.! Se actualiza la fecha con la del sistema.! Se almacena el importe total de la factura. 73

13 Seleccionando el Controlador. De acuerdo al patrón GRASP, y al contrato anterior, se selecciona como controlador el concepto TPV. Indicación de Fin de Venta. Se agrega un atributo escompletada, él cual toma el valor de True. Quién será responsable de modificar el atributo escompletada a true?. De acuerdo al patrón Experto, la misma clase Factura, deberá modificar dicho atributo, por lo tanto TPV enviará el mensaje completado(), a la clase Factura para que ésta lo ponga a true De igual forma la clase Factura deberá actualizar la fecha, tomando ésta del sistema y el consecutivo leído de la Factura anterior. Calculo del Total de la Factura. Responsabilidad. El calculo del total de la factura deberá ser responsabilidad de la clase que conoce la información Calculo. o La Venta Total es la suma de los subtotales de la suma de cada artículo. o El subtotal es igual a la cantidad * el precio de cada artículo. El atributo Total es de Factura, por lo tanto esta clase deberá ser la responsable del calculo del total. o o Cada subtotal deberá obtenerlo de la clase Venta y de la Clase Especificación del Producto (Esp_Producto) Deberá ir acumulando cada subtotal de cada instancia Venta hasta terminar todas las instancias almacenadas en la colección. El diagrama de colaboración completo quedará como sigue: : fin_venta() 2: escompletada() : TPV : Factura 4: total() : Vendedor 3: subtotal() : Esp_Producto : Venta 5: pr = lprecio(numero) Figura # 23, Contrato, fin_venta 74

14 Mostrado de Información. Durante la creación de los Diagramas de Colaboración, no se debe tomar en cuenta el mostrar información en pantalla, solo se debe de poner disponible la información. NOTA: No necesariamente se debe iniciar el Colaboración con el mensaje nombre del contrato, si el diseñador decide iniciar con otro mensaje, es libre de hacerlo. CONTRATO: entra_cliente CONTRATO: entra_cliente Nombre Responsabilidades Tipo Referencias cruzadas Notas Excepciones Salida Pre-condiciones Post-condiciones entra_cliente(numero) Accesar los datos del cliente para incluirlos en la Factura. Sistema R3 Accesa el Catalogo de Clientes. Envía un error si no existe el Cliente. Muestra los datos del Cliente. Se imprime la factura. Es necesario conocer la clave del cliente. De acuerdo al patrón GRASP, y al contrato anterior, se selecciona como controlador la Factura. : entra_cliente(numero) : Factura : Vendedor 2: Especifica(numero) : Esp_Cliente : Cat_Cliente 3: cte = busca(numero) Figura # 24, Contrato, entra_cliente 75

15 La clase que conoce a todos los clientes es la clase Catalogo de Clientes (Cat_cliente), va a buscar utilizando el número de cliente, los datos del cliente para agregarlos a la factura y ponerlos a disposición para poderlos mostrar Determinando Visibilidad. [Proceso] Como se mencionó anteriormente, la visibilidad es la habilidad que tiene un objeto de ver o tener referencia a otro objeto. Por lo tanto si un objeto emisor envía un mensaje a un objeto receptor, el emisor debe ser visible al receptor y el emisor debe tener algún tipo de referencia al receptor. Existen 4 tipos de visibilidad: Visibilidad como atributo o asociación. C es un atributo de B Visibilidad como Parámetro: C es un parámetro de un método de B Visibilidad declarada localmente: C es declarado como un objeto local en un método de B Visibilidad global: C es de alguna forma globalmente visible. Estos tipos son considerados cuando: un objeto de B envía un mensaje a un objeto C, C debe ser visible a B. Cuando se termino de desarrollar los diagramas de colaboración, se analiza el tipo de visibilidad que tendrá cada mensaje y una vez que se ha sido definido, el siguiente paso es el desarrollo del diagrama de clases. 6.7 Diseñando Diagramas de clase. [Proceso] El diagrama de clases se construye cuando han sido desarrollados los diagramas de interacción (aunque se pueden hacer paralelamente) y por supuesto con la ayuda del modelo conceptual. Las actividades y dependencias para la creación del Clases se muestran en la Figura # Diseñando Diagramas de Clases Un clases ilustra las especificaciones para las clases de software e interfases, esta información se incluye como sigue: Clases, asociaciones y atributos. Interfases, con sus operaciones y constantes. Métodos. atributos. navegabilidad. Dependencias. En contraste con el modelo conceptual, un diseño de un diagrama de clases presenta definiciones para entidades de software en lugar de conceptos del mundo real En el modelo conceptual, una Factura no representa una definición de software, es una abstracción de un concepto del mundo real. Un diseño de un clases expresa para la aplicación de software --- la definición de clases como componentes de software, por lo tanto, una clase Factura representará una clase de software. 76

16 Casos de Uso: Expandido y Esencial Casos de Uso: Real Caso de Uso Interacción Modelo Conceptual Glosario Clases Diagrama Secuencia Sistema Contratos de del Arquitectura de Paquetes Diagrama Estado de Base de Datos Figura # 25, Dependencias, Clases. Los pasos para diseñar un diagrama de clases son los siguientes:. Analizar los diagramas de interacción e identificar las clases que participan en la solución del software. Algunas clases del modelo conceptual pueden no estar presentes en el ciclo de desarrollo actual, pero tal vez sean manejadas en ciclos posteriores. 2. Dibujar cada una de ellas en un diagrama de clases. 3. Añadir los atributos de los conceptos asociados del modelo conceptual o las clases correspondientes en el diagrama de clases. 4. Analizar los diagramas de interacción para identificar y añadir los nombres de los métodos a su clase correspondiente. Tomar en cuenta que los métodos de creación generalmente son omitidos al igual que los métodos de simple acceso a atributos privados. También los mensajes a un multi-objeto son omitidos debido a que no pertenecen a una clase participante en el diagrama, sin embargo se puede añadir información acerca de esto. 5. Añadir el tipo de atributos, parámetros de los métodos y el valor de retorno de los métodos, aunque esto puede ser opcional. 6. Añadir las asociaciones necesarias de tal forma de soportar la visibilidad de los atributos. 7. Añadir las flechas de navegabilidad a las asociaciones para indicar la dirección de visibilidad de los atributos. La navegabilidad implica visibilidad, la más común; visibilidad como atributo. Esto no implica que todas las asociaciones deban ser adornadas con navegabilidad, se sugieren solo las siguientes: a. B envía un mensaje a C b. B crea una instancia de C c. B necesita mantener una asociación con C 77

17 8. Añadir relaciones de dependencia, las cuales indican una visibilidad de los siguientes tipos: parámetro, global o declarada localmente. Una relación de dependencia indica que un elemento tiene conocimiento de otro elemento y es representada mediante una flecha con línea punteada. 9. Pueden agregarse detalles como visibilidad, valores iniciales si es que estos son importantes Creando el clases del Problema del Vivero. [Caso de Estudio] Identificando clases de software. Se pueden encontrar analizando cada diagrama de colaboración. PTV Factura Venta Cat_Producto Esp_Producto Cat_Cliente Esp_Cliente El siguiente punto es dibujar un diagrama de clases para estas clases incluyendo los atributos previamente identificados en el modelo conceptual. TPV Cat_Cliente Factura numero : int fecha : Date importe : float Venta cantidad : int Esp_Cliente numero : int nombre : Cadena RFC : Cadena domicilio : Direccion Cat_producto Esp_Producto numero : int descripcion : Cadena precio : float Figura # 26, Clases obtenidas de los Diagramas de colaboración Algunos de los Conceptos del modelo conceptual pueden no aparecer en el Clases del ciclo de desarrollo actual, sin embargo, en ciclos de desarrollo futuros, en donde nuevos casos de uso los requieran, se deberán incluir en el diseño. 78

18 Agregando nombres de métodos. Los métodos que corresponden a cada clase pueden ser identificados analizando los Diagramas de Colaboración, de esta forma, por ejemplo; el mensaje escompletada() se envia a una instancia de la clase Factura, entonces la clase factura deberá definir el método escompletada(). En general, el conjunto de todos los mensajes enviados a una clase X a través de todos los Diagramas de Colaboración, se deberán incluir en la clase X. Por inspección de todos los Diagramas de Colaboración del caso de uso Facturación Versión, las clases quedarán conformadas como sigue: TPV entra_articulo(int numero, int cantidad) fin_venta() Venta num_art : int suma(venta Vi) subtotal() Cat_Cliente especifica(int numero) num_fact : int fecha : Date importe : float terminada : int Factura Esp_Cliente num_cte : int nombre : Cadena RFC : Cadena domicilio : Direccion suma_art(esp_producto prod, int cantidad) escompletada() total() entra_cliente(int numero) Cat_Producto especifica(int numero) Esp_Producto num_prod : int descripcion : Cadena precio : float precio(int numero) Figura # 27, Atributos y métodos NOTA: Algunos cambios... Se agrega el atributo terminada en la clase Factura, para indicar que fue concluida. Se cambia el nombre del atributo número en las clases; Venta, Factura, Esp_Cliente, Esp_Producto por; num_art, num_fact, num_cte y num_prod respectivamente. 79

19 Consideraciones en el nombres de métodos. Deberán tenerse en cuenta las siguientes consideraciones al nombrar métodos. a) Interpretación del mensaje crear(). En el UML este mensaje indica creación e inicialización, cuando se traslada el diseño a un lenguaje particular deberá considerarse el nombre de este método de acuerdo al lenguaje de programación empleado. Debido a sus múltiples interpretaciones y a que la inicialización es un trabajo muy común, es costumbre omitir este tipo de mensajes en el Diseño de clase. b) Métodos de acceso. Los métodos de acceso son aquellos que leen o actualizan atributos, es común contar con este tipo de métodos para cada atributo, así mismo declarar todos los atributos como privados. Este tipo de métodos son normalmente excluidos de los diagramas de clase ya que generan mucho ruido, pues si se tienen N atributos se generarán 2N métodos. c) Interpretación de mensajes a multiobjetos. Un mensaje a un multiobjeto es interpretado como un mensaje al contenedor / colección de objetos en si mismo. Por ejemplo el método buscar(numero) se deberá interpretar como un mensaje a una colección de objetos, por lo que el método buscar(numero) no es parte de la clase Esp_Producto, es parte de la definición del diccionario de clases, por lo cual será incorrecto agregarlo como un método de la clase Esp_Producto. Este tipo de clases contenedor son librerías de clases predefinidas, por lo que no es útil mostrar estos métodos en el diagrama de clases, ya que agregan ruido y muy poca información. d) Sintaxis dependiente del lenguaje. El UML usa su propia sintaxis, por lo tanto será necesario realizar una traslación al lenguaje que se usará en la implementación, esta traslación se deberá realizar durante la generación de código, en vez de durante la creación de los diagramas de clase e) Agregando información de tipos. El tipo de los atributos, parámetros de los métodos y valores de retorno de los métodos se pueden mostrar de una manera opcional Agregando asociaciones y navegabilidad. Cada terminación de una asociación es un rol, él cual puede ser adornado con una flecha para indicar navegabilidad. La navegabilidad es una propiedad del rol que indica el sentido de la navegación a través de la asociación desde el objeto de la clase fuente al objeto de la clase destino. La navegabilidad también indica visibilidad, usualmente visibilidad de atributos. La interpretación mas común de una asociación con una flecha de navegación es la visibilidad de atributos desde la clase fuente a la clase destino. Durante la implementación en un lenguaje de programación orientado a objetos se traslada indicando que la clase fuente tiene un atributo que se refiere a una instancia de la clase destino. En el diseño de un diagrama de clases, las asociaciones son seleccionadas de acuerdo a criterios de necesidad de conocer que asociaciones se requieren para satisfacer la visibilidad y necesidades de memoria indicadas por los diagramas de interacción. Esto es en contraste con las asociaciones en el modelo conceptual, las cuales se justifican por la intención de mejorar la comprensión del dominio del problema. Una vez mas, se aprecia una distinción en las metas en el diseño de los diagramas de clase y el modelo conceptual, uno es analítico y el otro es una descripción de los componentes de software. 80

20 La visibilidad requerida y las asociaciones entre clases son indicadas por los diagramas de interacción. Las siguientes son situaciones que sugieren la necesidad de definir una asociación con un adorno de navegabilidad entre B y C. a. B envía un mensaje a C b. B crea una instancia de C c. B necesita mantener una asociación con C Tomando en cuenta los criterios antes mencionados sobre asociaciones y navegabilidad, analizando los diagramas de colaboración generados anteriormente para el Caso de Uso de Facturación Versión, se construye el diagrama de clases de la Figura # 28. TPV entra_articulo(int numero, int cantidad) fin_venta() ve en Cat_Producto especifica(int numero) captura consulta Cat_Cliente especifica(int numero) contiene 0..* num_fact : int fecha : Date importe : float terminada : int Factura suma_art(esp_producto prod, int cantidad) escompletada() total() entra_cliente(int numero) contiene..* Esp_Producto num_prod : int descripcion : Cadena precio : float precio(int numero)..* Esp_Cliente num_cte : int nombre : Cadena RFC : Cadena domicilio : Direccion describe almacena..* Venta num_art : int suma(venta Vi) subtotal() Figura # 28, Clases Caso de Uso Facturación Versión En el diagrama de clase de la figura # 28 no existen las mismas asociaciones que se generaron en el modelo conceptual. Por ejemplo, en el modelo conceptual no existe una asociación entre Terminal de Punto de Venta (TPV) y el Catalogo de Clientes (Cat_Cliente), y en el Clases si existe se llama ve en ya que es necesario consultar el Catalogo de Clientes desde la Terminal de Punto de Venta. 8

21 Agregando Relaciones de Dependencia. El UML incluye una notación para indicar las Relaciones de Dependencia (una flecha punteada), él cual indica que un elemento tiene conocimiento de otro elemento. En las diagramas de clase las relaciones de dependencia son útiles para indicar atributos no visibles entre clases, en otras palabras; parámetros, visibilidad de declaraciones locales o globales. En contraste, la visibilidad planeada de los atributos se muestra mediante líneas de asociación y flechas de navegación. TPV entra_articulo(int numero, int cantidad) fin_venta() ve en Cat_Producto especifica(int numero) captura 0..* consulta Cat_Cliente especifica(int numero) contiene num_fact : int fecha : Date importe : float terminada : int Factura suma_art(esp_producto prod, int cantidad) escompletada() total() entra_cliente(int numero) contiene..* Esp_Producto num_prod : int descripcion : Cadena precio : float precio(int numero)..* Esp_Cliente num_cte : int nombre : Cadena RFC : Cadena domicilio : Direccion describe almacena..* Venta num_art : int suma(venta Vi) subtotal() Figura # 29, Clase, Dependencias. Caso de Uso Facturación, Versión En la Figura # 29 se muestran 2 dependencias, la primera es entre TPV y Esp_Producto, se da porque TPV recibe de Cat_Producto un objeto del tipo Esp_Producto regresado desde la función Cat_Producto.especifica(numero). La segunda dependencia se presenta entre Factura y Esp_Cliente, se da porque Factura debe recibir de Esp_Cliente un objeto del tipo Esp_Cliente regresado desde la función Cat_Cliente.especifica(numero). Estos atributos no visibles se pueden mostrar mediante la notación de dependencia. 82

6.8 La Arquitectura del Sistema. [Proceso]

6.8 La Arquitectura del Sistema. [Proceso] 6.8 La Arquitectura del Sistema. [Proceso] En el Caso de Estudio se ha hecho énfasis en los objetos del Dominio del problema, ya que representan la esencia del sistema y definen su comportamiento. Sin

Más detalles

PATRONES. Experto. Solución:

PATRONES. Experto. Solución: PATRONES. Experto. Asignar una responsabilidad a la clase que tiene la información necesaria para cumplirla. Cuál es el principio fundamental en virtud del cual asignaremos las responsabilidades a los

Más detalles

DISEÑO DE COMPONENTES DE SOFTWARE *

DISEÑO DE COMPONENTES DE SOFTWARE * DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP * Resumen del capítulo 10 de libro de [Pressman 2010] V:18-11-2008 (c) P. Gomez-Gil, INAOE.

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Diagramas de Clase en UML 1.1

Diagramas de Clase en UML 1.1 Diagramas de Clase en UML. Francisco José García Peñalvo Licenciado en Informática. Profesor del Área de Lenguajes y Sistemas Informáticos de la Universidad de Burgos. fgarcia@.ubu.es Carlos Pardo Aguilar

Más detalles

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos 3.3 EL MÉTODO DE BOOCH. 3.3. Introducción. El método cuenta con una notación expresiva y bien definida que le permite al diseñador comunicar sus ideas y concentrarse en problemas más serios. Para la captura

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

Curso Taller de Arquitectura de Software usando UML

Curso Taller de Arquitectura de Software usando UML Curso Taller de Arquitectura de Software usando UML Presentación: Este curso comprende las técnicas necesarias para el modelamiento de sistemas a través de los diagramas definidos por UML (Unified Modelling

Más detalles

Tema 5. Diseño detallado.

Tema 5. Diseño detallado. Ingeniería del Software II 2011 Tema 5. Diseño detallado. Diseño del Software. Los requisitos y el análisis orientado a objetos se centran en aprender a hacer lo correcto: Entender los objetos de nuestro

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

ISO 19103. Lenguaje de Esquema Conceptual

ISO 19103. Lenguaje de Esquema Conceptual ISO 19103 Lenguaje de Esquema Conceptual La ISO 19103 establece normas y guías para la adopción y uso de un Lenguaje de Esquema Conceptual (CSL) para desarrollar modelos o esquemas de información geográfica,

Más detalles

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS 4.1 Diferencias entre análisis y diseño La división entre el análisis y diseño es poco clara, el trabajo de los dos se mezcla continuamente

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

Más detalles

Capitulo III. Diseño del Sistema.

Capitulo III. Diseño del Sistema. Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje

Más detalles

El Modelo Conceptual

El Modelo Conceptual El Modelo Conceptual Ilustra: Conceptos (Objetos) en el dominio del problema. Es el instrumento (artefacto) más importante de crear en el AOO. Es la representación de cosas del mundo real y NO de componentes

Más detalles

INGENIERÍA DEL SOFTWARE I. Univ. Cantabria Fac. de Ciencias. Especificación de Requisitos. Práctica 2

INGENIERÍA DEL SOFTWARE I. Univ. Cantabria Fac. de Ciencias. Especificación de Requisitos. Práctica 2 INGENIERÍA DEL SOFTWARE I Práctica 2 Especificación de Requisitos Univ. Cantabria Fac. de Ciencias María Sierra y Patricia López Nociones de UML para Requisitos: Casos de Uso Caso de Uso Una descripción

Más detalles

Tutorial de UML. Introducción: Objetivos: Audiencia: Contenidos:

Tutorial de UML. Introducción: Objetivos: Audiencia: Contenidos: Tutorial de UML Introducción: El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende

Más detalles

DIAGRAMAS DE SECUENCIA DEL SISTEMA, CONTRATOS DE LAS OPERACIONES DEL SISTEMA, GLOSARIO Y PAQUETES

DIAGRAMAS DE SECUENCIA DEL SISTEMA, CONTRATOS DE LAS OPERACIONES DEL SISTEMA, GLOSARIO Y PAQUETES DIAGRAMAS DE SECUENCIA DEL SISTEMA, CONTRATOS DE LAS OPERACIONES DEL SISTEMA, GLOSARIO Y PAQUETES Extraído de: UML y Patrones. 2ª Edición. Craig Larman. Prentice Hall. 2003. Diagramas de Secuencia del

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

M III ABSTRACCIÓN Y CLASIFICACIÓN

M III ABSTRACCIÓN Y CLASIFICACIÓN M III ABSTRACCIÓN Y CLASIFICACIÓN COMPLEJIDAD Y ABSTRACCIÓN La abstracción en el desarrollo del programario En todo el proceso de abstracción siempre hay una parte de la situación o del problema que se

Más detalles

Actividad ASI 1: Definición del Sistema

Actividad ASI 1: Definición del Sistema Actividad ASI 1: Definición del Sistema Descripción del sistema, delimitando su alcance Establecimiento de interfaces con otros sistemas Identificación de usuarios representativos ASI 1.1 Determinación

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

Introducción al UML. Domingo Hernández H. Escuela de Ingeniería de Sistemas Departamento de computación

Introducción al UML. Domingo Hernández H. Escuela de Ingeniería de Sistemas Departamento de computación Introducción al UML Domingo Hernández H. Escuela de Ingeniería de Sistemas Departamento de computación Contenido Qué es UML?. Diagramas Utilizados en UML. Ejemplos. Qué es UML UML es un Lenguaje de Modelado

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

Los requisitos de un Sistema de Información

Los requisitos de un Sistema de Información Captura de requisitos Captura de Requisitos en el PUD Los requisitos de un Sistema de Información Modelo de Casos de Uso Otros instrumentos 1 Iteración en PUD Planificación de la Iteración Captura de requisitos:

Más detalles

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

ANÁLISIS Y DISEÑO DE UN PORTAL DE VENTA DE LIBROS EDUCATIVOS

ANÁLISIS Y DISEÑO DE UN PORTAL DE VENTA DE LIBROS EDUCATIVOS INGENIERIA DE SOFTWARE Trabajo Final de Carrera ANÁLISIS Y DISEÑO DE UN PORTAL DE VENTA DE LIBROS EDUCATIVOS Jordi Cid Rodríguez - ETIG - Consultor: José Antonio Raya Martos Septiembre 2011 Objetivo El

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

DEFINICION, ANALISIS Y DISEÑO DE UN SISTEMA DE INTRANET PARA UNA EMPRESA PRODUCTORA DE BIENES Y SERVICIOS PARA EL SECTOR ELECTRICO COLOMBIANO

DEFINICION, ANALISIS Y DISEÑO DE UN SISTEMA DE INTRANET PARA UNA EMPRESA PRODUCTORA DE BIENES Y SERVICIOS PARA EL SECTOR ELECTRICO COLOMBIANO UNIVERSIDAD NACIONAL DE COLOMBIA SEDE MEDELLÍN FACULTAD DE MINAS ESCUELA DE SISTEMAS E INFORMÁTICA TRABAJO DE GRADO DEFINICION, ANALISIS Y DISEÑO DE UN SISTEMA DE INTRANET PARA UNA EMPRESA PRODUCTORA DE

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

UML. Lenguaje de Modelado Unificado

UML. Lenguaje de Modelado Unificado Lenguaje de Modelado Unificado Concepto de Reseña Histórica Características Estándares que conforman Modelo Relacional con Ventajas Críticas Concepto de (Unified( Modeling language) Es un lenguaje usado

Más detalles

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de los

Más detalles

DCU Diagramas de casos de uso

DCU Diagramas de casos de uso DCU Diagramas de casos de uso Universidad de Oviedo Departamento de Informática Contenidos Introducción Elementos básicos Más sobre los actores Más sobre los casos de uso Más sobre las asociaciones Otros

Más detalles

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto.

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICES En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICE 1. Herramientas Las herramientas que se usaron en el análisis, desarrollo

Más detalles

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas Departamento de Informática PROGRAMACIÓN DIDÁCTICA Curso 11-12 1 CONSEJERÍA DE EDUCACIÓN I.E.S. NERVIÓN Departamento de Informática CICLO FORMATIVO: TÉCNICO SUPERIOR EN DESARROLLO DE APLICACIONES MULTIPLATAFORMA.

Más detalles

CAPITULO 4. Requerimientos, Análisis y Diseño. El presente capítulo explica los pasos que se realizaron antes de implementar

CAPITULO 4. Requerimientos, Análisis y Diseño. El presente capítulo explica los pasos que se realizaron antes de implementar CAPITULO 4 Requerimientos, Análisis y Diseño El presente capítulo explica los pasos que se realizaron antes de implementar el sistema. Para esto, primero se explicarán los requerimientos que fueron solicitados

Más detalles

Generación de código a partir de UML

Generación de código a partir de UML Generación de código a partir de UML Ingeniería del Software Curso 2006/2007 Índice De la etapa de diseño al código De la etapa de implementación al código Generación de código: Herramientas Flujo de trabajo

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Notación UML para modelado Orientado a Objetos

Notación UML para modelado Orientado a Objetos 1 Notación UML para modelado Orientado a Objetos 2 Notación UML para modelado Orientado a Objetos Índice 1.1. Qué es UML?.. 3 1.2. Por qué interesa UML en la asignatura de Programación Orientada a Objetos?3

Más detalles

Modelado con Casos de Uso (CU)

Modelado con Casos de Uso (CU) Universidad de Congreso Modelado con Casos de Uso (CU) Análisis de Sistemas 2do año Qué es el modelado de Casos de uso? Una forma de capturar el comportamiento deseado del sistema a desarrollar Una manera

Más detalles

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

2. Conceptos básicos Abstracción La abstracción como un proceso mental natural La abstracción en el desarrollo de software

2. Conceptos básicos Abstracción La abstracción como un proceso mental natural La abstracción en el desarrollo de software 2. Conceptos básicos Hoy en día las aplicaciones son demasiado voluminosas y complejas para ser manejadas por una sola persona. Las aplicaciones de software son complejas porque modelan la complejidad

Más detalles

INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN

INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN INDICE Introducción...2 Frontera de la aplicación...3 Cuenta de Puntos Función sin ajustar...3 Funciones de Datos...4 Funciones Transaccionales...4 Mecanismo...5

Más detalles

Guía de uso para el registro de Planes y Programas de Capacitación y Adiestramiento vía internet

Guía de uso para el registro de Planes y Programas de Capacitación y Adiestramiento vía internet Guía de uso para el registro de Planes y Programas de Capacitación y Adiestramiento vía internet Versión 1.0 2 ÍNDICE 1. Introducción... 5 2. Solicitud y Administración de claves de acceso... 6 2.1 Solicitud

Más detalles

2.4 Modelado conceptual

2.4 Modelado conceptual 2.4 Modelado conceptual 2.4. Búsqueda de conceptos Un modelo conceptual muestra clases conceptuales significativas en un dominio del problema; es el artefacto más importante que se crea durante el análisis

Más detalles

Patrones de Diseño Orientados a Objetos 2 Parte

Patrones de Diseño Orientados a Objetos 2 Parte Patrones de Diseño Orientados a Objetos 2 Parte Patrón Observador Observer (Patrón de Comportamiento) Patrón Observador Observer Observador (en inglés: Observer) es un patrón de diseño que define una dependencia

Más detalles

Especificación de Requisitos del Sistema de Registro y Control de Bienes Muebles de la ULA (ULA_SRCBM, versión 1.0)

Especificación de Requisitos del Sistema de Registro y Control de Bienes Muebles de la ULA (ULA_SRCBM, versión 1.0) Proyecto: Actualización del Sistema de Información de Muebles Documento: Especificación de s del Sistema de Registro y Control de Muebles ULA (ULA_SRCBM, versión 1.0) Elaborado por: William J. Montilva

Más detalles

Análisis de Requerimientos

Análisis de Requerimientos Análisis de Requerimientos Ing. Luis Zuloaga Rotta Situación de la Industria de Software Mas del 30% de todos los proyectos de software son cancelados antes de su finalización. Mas del 70% de los proyectos

Más detalles

Fundamentos de Ingeniería del Software. Capítulo 3. Análisis de Requisitos Introducción a los casos de uso

Fundamentos de Ingeniería del Software. Capítulo 3. Análisis de Requisitos Introducción a los casos de uso Fundamentos de Ingeniería del Software Capítulo 3. Análisis de Requisitos Introducción a los casos de uso Cap 3. Análisis de Requisitos Estructura 1. Actividades iniciales. 2. Técnicas de recogida de la

Más detalles

CAPITULO V. HERRAMIENTA CASE (Rational Rose, C++)

CAPITULO V. HERRAMIENTA CASE (Rational Rose, C++) CAPITULO V HERRAMIENTA CASE (Rational Rose, C++) 5.1 HERRAMIENTA CASE La documentación del UML ha propiciado el desarrollo de herramientas CASE, las cuales cubren el ciclo de vida del software y además

Más detalles

Programación Avanzada. Análisis Modelado del Dominio

Programación Avanzada. Análisis Modelado del Dominio Programación Avanzada Análisis Modelado del Dominio Contenido Introducción Modelo de Dominio Conceptos Asociaciones Atributos Generalizaciones Otros elementos Restricciones Programación Avanzada Análisis:

Más detalles

DIPLOMADO EN TECNOLOGÍAS DE LA INFORMACIÓN

DIPLOMADO EN TECNOLOGÍAS DE LA INFORMACIÓN DIPLOMADO EN TECNOLOGÍAS DE LA INFORMACIÓN MODULO I: Análisis y Diseño de Sistemas El alumno se familiarizará y describirá los conceptos y aspectos fundamentales del Análisis y Diseño Orientado a Objetos

Más detalles

EXAMEN FINAL Metodología y Programación Orientada a Objetos. Curso 2010 2011. Cuatrimestre de otoño. 17 de Enero de 2011

EXAMEN FINAL Metodología y Programación Orientada a Objetos. Curso 2010 2011. Cuatrimestre de otoño. 17 de Enero de 2011 EXAMEN FINAL Metodología y Programación Orientada a Objetos. Curso 2010 2011. Cuatrimestre de otoño. 17 de Enero de 2011 1. (0,75 PUNTOS) Identificad a continuación las sentencias que son ciertas, descartando

Más detalles

Capítulos 2 y 5: Modelación con UML y Modelo Objeto

Capítulos 2 y 5: Modelación con UML y Modelo Objeto Capítulos 2 y 5: Modelación con UML y Modelo Objeto Asignando Responsabilidades 2 Responsabilidades son obligaciones de un objeto, o comportamiento relacionado a su rol en el sistema Qué hace un objeto?

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera. Departamento de Lenguajes y Sistemas Informáticos

Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera. Departamento de Lenguajes y Sistemas Informáticos Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera Departamento de Lenguajes y Sistemas Informáticos INDICE 1. Introducción. 2. Documentación del Proyecto de Fin de

Más detalles

BPMN BPMN BPMN. BPD Objetos de flujo - Actividades. BPD (Business Process Diagram) Notación de modelado de procesos de negocio BPD

BPMN BPMN BPMN. BPD Objetos de flujo - Actividades. BPD (Business Process Diagram) Notación de modelado de procesos de negocio BPD BPMN Notación de modelado de procesos de negocio BPMN Fue desarrollado por la BPMI (Business Process Management Initiative) Objetivos: Proveer una notación entendible para cualquiera desde el analista

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Tema 1. Introducción a los TAD

Tema 1. Introducción a los TAD Tema 1. Introducción a los TAD Objetivos En este tema nos ocupamos inicialmente del concepto de abstracción, dedicando la mayor atención a la abstracción de datos, estudiando aspectos relacionados con

Más detalles

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s Especificación de requerimientos Diseño de bases de datos Documento de especificación del sistema 1. Definición del problema 2. Descripción funcional 2. 3. Restricciones 4. Diagramas de flujo de datos

Más detalles

Ejemplo de Análisis Orientado a Objetos ATMs

Ejemplo de Análisis Orientado a Objetos ATMs Ejemplo de Análisis Orientado a Objetos ATMs Se desea diseñar el software necesario para una red bancaria provista de cajeros automáticos (ATMs), que serán compartidos por un consorcio de bancos. Cada

Más detalles

CAPÍTULO 5. DESARROLLO Y PRUEBAS

CAPÍTULO 5. DESARROLLO Y PRUEBAS CAPÍTULO 5. DESARROLLO Y PRUEBAS 5.1 Introducción a las Tecnologías 5.1.1 Herramientas 5.1.1.1 SQL Server Es un sistema que sirve para la gestión de base de datos basado en un modelo relacional. Así mismo

Más detalles

Introducción a los Tipos Abstractos de Datos

Introducción a los Tipos Abstractos de Datos Página 1 de 8 Introducción a los Tipos Abstractos de Datos Introducción: Concepto de abstracción Abstracción funcional y abstracción de datos Construcción de tipos abstractos de datos Especificación de

Más detalles

UNIDAD Nº 4. Construcción de un Modelo Conceptual

UNIDAD Nº 4. Construcción de un Modelo Conceptual UNIDAD Nº 4 Construcción de un Modelo Conceptual 1. Introducción Un Modelo Conceptual explica (a sus creadores) los conceptos significativos en un dominio del problema, es el artefacto más importante a

Más detalles

Programación Avanzada SOLUCIÓN EXAMEN FEBRERO 2011

Programación Avanzada SOLUCIÓN EXAMEN FEBRERO 2011 Programación Avanzada SOLUCIÓN EXAMEN FEBRERO 2011 Por favor siga las siguientes indicaciones: Escriba con lápiz y de forma prolija. Escriba las hojas de un solo lado Escriba su nombre y número de documento

Más detalles

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS CURSO: JAVA BASICO PROFESOR: EMERSON CASTAÑEDA SANABRIA TEMA: Programación Orientada a Objetos OBJETIVOS: Familiarizarse con la Programación

Más detalles

Técnicas de Desarrollo de Programas Ingeniería Informática Curso 2008 / 2009. Ejercicios de Patrones de Diseño:

Técnicas de Desarrollo de Programas Ingeniería Informática Curso 2008 / 2009. Ejercicios de Patrones de Diseño: Técnicas de Desarrollo de Programas Ingeniería Informática Curso 2008 / 2009 Ejercicios de Patrones de Diseño: Iterator, Composite, Strategy, Observer, Decorator, Visitor Ejercicio 1 (examen de junio año

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

DEPARTAMENTO: Informática. MATERIA: Programación. NIVEL: 1º Desarrollo de Aplicaciones Multiplataforma

DEPARTAMENTO: Informática. MATERIA: Programación. NIVEL: 1º Desarrollo de Aplicaciones Multiplataforma DEPARTAMENTO: Informática MATERIA: Programación NIVEL: 1º Desarrollo de Aplicaciones Multiplataforma 1. Objetivos. Competencias Profesionales, Personales y Sociales 1.1 Objetivos del ciclo formativo La

Más detalles

Patrones de diseño. Programación III.I.T.I. de Sistemas. Contenidos. Información sobre patrones de diseño. Motivación.

Patrones de diseño. Programación III.I.T.I. de Sistemas. Contenidos. Información sobre patrones de diseño. Motivación. Departamento de Informática Universidad de Valladolid Programación III.I.T.I. de Sistemas Patrones 1 Contenidos Programación III.I.T.I. de Sistemas Patrones de diseño Patrones de diseño Introducción Conceptos

Más detalles

La importancia del desarrollo para el buen diseño del software

La importancia del desarrollo para el buen diseño del software La importancia del desarrollo para el buen diseño del software RESUMEN N L González Morales. 1 En este ensayo se examinan los temas vistos en clase que son Desarrollo de Orientado a Objetos y Arquitectura

Más detalles

3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1.

3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1. 3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1. Compartimento del nombre...21 3.2.2.2. Compartimento de la lista

Más detalles

Unidad II. Metodología para resolver problemas aplicando la POO. Parte 3 Análisis del Problema Modelo del Dominio

Unidad II. Metodología para resolver problemas aplicando la POO. Parte 3 Análisis del Problema Modelo del Dominio Unidad II Metodología para resolver problemas aplicando la POO Parte 3 Análisis del Problema Modelo del Dominio 1 FASE II. Análisis del problema Incluye: Modelo de casos de uso Modelo del dominio Tareas:

Más detalles

TFC. Ingeniería de Software MEMORIA. Consultor: Juan José Cuadrado Gallego

TFC. Ingeniería de Software MEMORIA. Consultor: Juan José Cuadrado Gallego TFC Ingeniería de Software Alumno: Halyna Klachko Consultor: Juan José Cuadrado Gallego Índice 1. Identificación del proyecto..5 1.1 Introducción...5 1.2 Objetivos del proyecto..5 1.3 Descripción general..5

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

Más detalles

Diseño orientado a los objetos

Diseño orientado a los objetos Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Títol: Intranet Diagonal Recobros. Volum: 1/1 Alumne: Miguel Meneses Nicolau

Títol: Intranet Diagonal Recobros. Volum: 1/1 Alumne: Miguel Meneses Nicolau Títol: Intranet Dianal Recobros Volum: 1/1 Alumne: Miguel Meneses Nicolau Director/Ponent: Carles Farré Tost Departament: Lenguajes y Sistemas Informaticos Data: 22/05/2010 DADES DEL PROJECTE Títol

Más detalles

Aplicación gratuita para la Generación y Certificación de CFDI

Aplicación gratuita para la Generación y Certificación de CFDI Aplicación gratuita para la Generación y Certificación de CFDI 1 MANUAL DE USUARIO Contenido Descripción... 3 Requerimientos mínimos... 3 Registro... 3 Ingreso al sistema... 3 Registro de CSD... 5 Datos

Más detalles

Sistema Automatizado para la Entrega y Recepción (SISER-WEB)

Sistema Automatizado para la Entrega y Recepción (SISER-WEB) Sistema Automatizado para la Entrega y Recepción (SISER-WEB) ÍNDICE INTRODUCCIÓN OBJETIVO REQUERIMIENTOS ACCESO AL SISTEMA NORMATIVIDAD MANUAL SISTEMA AUTOMATIZADO I. ESTADISTICAS DE CUMPLIMIENTO II. III.

Más detalles

Sistema para el alquiler, control de películas y clientes en una videotienda

Sistema para el alquiler, control de películas y clientes en una videotienda CASO DE PRUEBA: Sistema para el alquiler, control de películas y clientes en una videotienda Documento de arquitectura Y servicios Versión Historia de Revisión Fecha Versión Descripción Responsable

Más detalles

Técnicas de desarrollo de aplicaciones en Métrica V3

Técnicas de desarrollo de aplicaciones en Métrica V3 Índice de contenido Técnicas de desarrollo de aplicaciones en Métrica V3 Técnicas de desarrollo de aplicaciones en Métrica V3...1 Licencia...1 Introducción...1 Técnicas de desarrollo...1 Análisis coste-beneficio...2

Más detalles

Patterns & Practices. Catálogo de templates. HelpDesk. Versión: 2.0. Fecha de publicación 08-04-2011. Aplica a: Q-flow 3.0 y Q-flow 3.

Patterns & Practices. Catálogo de templates. HelpDesk. Versión: 2.0. Fecha de publicación 08-04-2011. Aplica a: Q-flow 3.0 y Q-flow 3. Catálogo de templates HelpDesk Versión: 2.0 Fecha de publicación 08-04-2011 Aplica a: Q-flow 3.0 y Q-flow 3.1 Índice Introducción... 3 Diseño... 4 Implementación... 6 Grafo... 6 Roles... 7 Datos de aplicación...

Más detalles

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño El proceso de diseño para una base de datos consta básicamente de 7 pasos, los cuáles se describen en la siguiente imagen.

Más detalles

PEEPER PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS. Mayo 2014. Versión 2.1 OSCAR IVAN LÓPEZ PULIDO

PEEPER PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS. Mayo 2014. Versión 2.1 OSCAR IVAN LÓPEZ PULIDO PEEPER Implementación del cambio de técnica usada para la actualización de datos en los reportes de esfuerzo, usados como métrica de productividad, progreso y costo de los proyectos, de la compañía de

Más detalles

UNIDAD DIDACTICA 2 Lenguaje Unificado de Modelado(UML) 1. INTRODUCCIÓN Y TIPOS DE DIAGRAMAS

UNIDAD DIDACTICA 2 Lenguaje Unificado de Modelado(UML) 1. INTRODUCCIÓN Y TIPOS DE DIAGRAMAS UNIDAD DIDACTICA 2 Lenguaje Unificado de Modelado(UML) 1. INTRODUCCIÓN Y TIPOS DE DIAGRAMAS 1.1 Qué es el UML? UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura

Más detalles

Capítulo 2. Planteamiento del problema. Capítulo 2 Planteamiento del problema

Capítulo 2. Planteamiento del problema. Capítulo 2 Planteamiento del problema Capítulo2 Planteamientodelproblema 38 2.1Antecedentesycontextodelproyecto En lo que respecta a los antecedentes del proyecto, se describe inicialmente el contexto donde se utiliza el producto de software.

Más detalles

Creando Arquitecturas

Creando Arquitecturas Creando Arquitecturas orientadas a servicios SOA Suite Abril 2013 Buenos Aires - Argentina Índice 1. Introducción. 2. Nuestro camino para la creación de SOAs. 3. Como justificar el cambio? 4. Nuestras

Más detalles

Pauta de Informe de Proyecto

Pauta de Informe de Proyecto Departamento de Informática Universidad Técnica Federico Santa María Pauta de Informe de Proyecto ILI-236 Profesores: Hernán Astudillo y Marcello Visconti 1 Introducción... 3 2 Plan de trabajo... 3 3 Análisis...

Más detalles

Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo

Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes

Más detalles