Desarrollo Orientado a Objetos con UML

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

Download "Desarrollo Orientado a Objetos con UML"

Transcripción

1 Desarrollo Orientado a Objetos con UML Facultad de Informática UPM

2

3 Índice I UML...1 I.1 Introducción...1 II NOTACIÓN BÁSICA UML...3 II.1 Modelos...3 II.2 Elementos Comunes a Todos los Diagramas...3 II.2.1 Notas...3 II.2.2 Dependencias...3 II.3 Diagramas de Estructura Estática...4 II.3.1 Clases...4 II.3.2 Objetos...5 II.3.3 Asociaciones...5 II Nombre de la Asociación y Dirección...5 II Multiplicidad...6 II Roles...6 II Agregación...7 II Clases Asociación...7 II Asociaciones N-Arias...7 II Navegabilidad...8 II.3.4 Herencia...8 II.3.5 Elementos Derivados...9 II.4 Diagrama de Casos de Uso...9 II.4.1 Elementos...9 II Actores...9 II Casos de Uso...9 II Relaciones entre Casos de Uso...9 II.5 Diagramas de Interacción...10 II.5.1 Diagrama de Secuencia...10 II.5.2 Diagrama de Colaboración...11 II.6 Diagrama de Estados...12 III NOTACIÓN AVANZADA UML...14 III.1 Modelado Dinámico...14 III.1.1 Diagramas De Actividades...14 III.1.2 Contenido del diagrama de actividades...14 III Estados de actividad y estados de acción...14 III Transiciones...15 III Bifurcaciones...16 III División y unión...16 III Calles...16 III.2 Modelado Físico De Un Sistema OO...17 i

4 III.2.1 Componentes...17 III Interfaces...18 III Tipos de componentes...19 III Organización de componentes...19 III Estereotipos de componentes...19 III.2.2 Despliegue...19 III Nodos...19 III Nodos y componentes...20 III.2.3 Diagramas de Componentes...21 III Algunos conceptos...21 III Usos más comunes...21 III.2.4 Diagramas de Despliegue...22 III Técnicas más comunes de modelado...22 III.2.5 Arquitectura del Sistema...23 III Arquitectura de tres niveles...23 III Arquitectura de tres niveles orientadas a objetos...23 III Arquitectura MULTI-nivel...23 III Paquetes...24 III Identificación de Paquetes...24 IV DESARROLLO ORIENTADO A OBJETOS...25 IV.1 Proceso de Desarrollo...25 IV.1.1 Visión General...25 IV.2 Fase de Planificación y Especificación de Requisitos...27 IV.2.1 Actividades...27 IV.2.2 Requisitos...27 IV.2.3 Casos de Uso...28 IV Casos de Uso de Alto Nivel...28 IV Casos de Uso Expandidos...28 IV Identificación de Casos de Uso...30 IV Identificación de los Límites del Sistema...30 IV Tipos de Casos de Uso...30 IV Consejos Relativos a Casos de Uso...31 IV.2.4 Construcción del Modelo de Casos de Uso...32 IV.2.5 Planificación de Casos de Uso según Ciclos de Desarrollo...33 IV Caso de Uso Inicialización...34 IV.3 Fase de Construcción: Análisis...34 IV.3.1 Actividades...34 IV.3.2 Modelo Conceptual...35 IV Identificación de Conceptos...35 IV Creación del Modelo Conceptual...36 IV Identificación de Asociaciones...36 IV Identificación de Atributos...37 IV.3.3 Glosario...38 IV.3.4 Diagramas de Secuencia del Sistema...38 IV Construcción de un Diagrama de Secuencia del Sistema...39 IV.3.5 Contratos de Operaciones...39 IV Construcción de un Contrato...40 IV Post-condiciones...41 IV.3.6 Diagramas de Estados...41 IV.4 Fase de Construcción: Diseño...41 IV.4.1 Actividades...41 IV.4.2 Casos de Uso Reales...42 IV.4.3 Diagramas de Colaboración...42 IV Creación de Diagramas de Colaboración...42 ii

5 IV.4.4 Diagrama de Clases de Diseño...43 IV Relaciones de Dependencia para Representar Visibilidad entre Clases...44 IV Construcción de un Diagrama de Clases de Diseño...45 IV Navegabilidad...46 IV Visibilidad de Atributos y Métodos...46 IV.4.5 Otros Aspectos en el Diseño del Sistema...46 IV.5 Fases de Implementación y Pruebas...46 V BIBLIOGRAFÍA...47 iii

6

7 I.1 Introducción 1 I UML I.1 Introducción UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estándar de facto de la industria, debido a que ha sido concebido por los autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Estos autores fueron contratados por la empresa Rational Software Co. para crear una notación unificada en la que basar la construcción de sus herramientas CASE. En el proceso de creación de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, así como grupos de analistas y desarrolladores. Figura 1 Logo de UML Esta notación ha sido ampliamente aceptada debido al prestigio de sus creadores y debido a que incorpora las principales ventajas de cada uno de los métodos particulares en los que se basa: Booch, OMT y OOSE. UML ha puesto fin a las llamadas guerras de métodos que se han mantenido a lo largo de los 90, en las que los principales métodos sacaban nuevas versiones que incorporaban las técnicas de los demás. Con UML se fusiona la notación de estas técnicas para formar una herramienta compartida entre todos los ingenieros software que trabajan en el desarrollo orientado a objetos. Booch 91 OMT - 1 Otros Métodos OOSE Booch 93 OMT - 2 Revisión por parte del público Unified Method 0.8 UML 0.9 y 0.91 OOPSLA 95 Junio del 96 y Octubre del 97 Experiencia de las empresas participantes en UML UML 1.0 Enero del 97 UML 1.1 Septiembre del 97 Figura 2 Historia de UML

8 2 I.1 Introducción El objetivo principal cuando se empezó a gestar UML era posibilitar el intercambio de modelos entre las distintas herramientas CASE orientadas a objetos del mercado. Para ello era necesario definir una notación y semántica común. En la Figura 2 se puede ver cuál ha sido la evolución de UML hasta la creación de UML 1.1. Hay que tener en cuenta que el estándar UML no define un proceso de desarrollo específico, tan solo se trata de una notación. En este curso se sigue el método propuesto por Craig Larman [Larman99] que se ajusta a un ciclo de vida iterativo e incremental dirigido por casos de uso. En la parte II de este texto se expone la notación y semántica básica de UML, en la parte III se presentan conceptos avanzados de la notación UML, mientras que en la parte IV se presenta el método de desarrollo orientado a objetos de Larman, que se sirve de los modelos de UML que se han visto anteriormente.

9 II.1 Modelos 3 II Notación básica UML En esta parte se verá cómo se representan gráficamente en UML los conceptos principales de la orientación a objetos. II.1 Modelos Un modelo representa a un sistema software desde una perspectiva específica. Al igual que la planta y el alzado de una figura en dibujo técnico nos muestran la misma figura vista desde distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema. 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. II.2 Elementos Comunes a Todos los Diagramas II.2.1 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. Una nota se representa como un rectángulo con una esquina doblada con texto en su interior. Puede aparecer en un diagrama tanto sola como unida a un elemento por medio de una línea discontinua. Puede contener restricciones, comentarios, el cuerpo de un procedimiento, etc. Usuario puede ser cualquiera de los actores definidos en el sistema Usuario Figura 3 Ejemplo de nota II.2.2 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).

10 4 II.3 Diagramas de Estructura Estática Pueden existir dependencias entre dos elementos cualesquiera Clase dependiente Clase de la que depende Figura 4 Dependencias II.3 Diagramas de Estructura Estática Con el nombre de Diagramas de Estructura Estática se engloba tanto al Modelo Conceptual de la fase de Análisis como al Diagrama de Clases de la fase de Diseño. Ambos son distintos conceptualmente, mientras el primero modela elementos del dominio el segundo presenta los elementos de la solución software. Sin embargo, ambos comparten la misma notación para los elementos que los forman (clases y objetos) y las relaciones que existen entre los mismos (asociaciones). II.3.1 Clases Una clase se representa mediante una caja subdividida en tres partes: En la superior se muestra el nombre de la clase, en la media los atributos y en la inferior las operaciones. Una clase puede representarse de forma esquemática (plegada), con los detalles como atributos y operaciones suprimidos, siendo entonces tan solo un rectángulo con el nombre de la clase. En la Figura 5 se ve cómo una misma clase puede representarse a distinto nivel de detalle según interese, y según la fase en la que se esté. Clase con detalles a nivel de análisis Termostato temperatura_deseada temperatura_muestreada establecer_temp () Clase con detalles de implementación Termostato +temperatura_deseada: Temperatura = 20 #temperatura_muestreada: Temperatura Clase con detalles suprimidos Termostato +establecer_temp (valor: Temperatura) Figura 5 Notación para clases a distintos niveles de detalle

11 II.3 Diagramas de Estructura Estática 5 II.3.2 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. Objeto de la clase Termostato sin nombre específico Objeto Eje_de_coordenadas de la clase Punto Eje_de_coordenadas: Punto :Termostato temperatura_deseada = 20 temperatura_muestreada = 18 establecer_temp () coordenada_x = 0 coordenada_y = 0 Objeto p1de la clase Punto p1: Punto coordenada_x = 8,53 coordenada_y = 41,29 Figura 6 Ejemplos de objetos II.3.3 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. II 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. En el ejemplo de la Figura 7 se puede leer la asociación como Director manda sobre Empleado. Director manda sobre Empleado Figura 7 Ejemplo de asociación con nombre y dirección Los nombres de las asociaciones normalmente se incluyen en los modelos para aumentar la legibilidad. Sin embargo, en ocasiones pueden hacer demasiado abundante la información que

12 6 II.3 Diagramas de Estructura Estática se presenta, con el consiguiente riesgo de saturación. En ese caso se puede suprimir el nombre de las asociaciones consideradas como suficientemente conocidas. En las asociaciones de tipo agregación y de herencia no se suele poner el nombre. II Multiplicidad Corresponde_a Cuenta Bancaria 1 * Operación Nieto * Vive_con 0..4 Abuelo 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: 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). II Roles Figura 8 Ejemplos de multiplicidad en asociaciones 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. Empresa Emplea * 1..* Contratante Empleado Trabajador Persona 2 Padre Hijo * Es_padre_de Figura 9 Ejemplo de roles en una asociación

13 II.3 Diagramas de Estructura Estática 7 II 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. CPU Ordenador Pantalla Teclado Figura 10 Ejemplo de agregación II Clases Asociación Cuando una asociación tiene propiedades propias se representa como una clase unida a la línea de la asociación por medio de una línea a trazos. Tanto la línea como el rectángulo de clase representan el mismo elemento conceptual: la asociación. Por tanto ambos tienen el mismo nombre, el de la asociación. Cuando la clase asociación sólo tiene atributos el nombre suele ponerse sobre la línea (como ocurre en el ejemplo de la Figura 11). Por el contrario, cuando la clase asociación tiene alguna operación o asociación propia, entonces se pone el nombre en la clase asociación y se puede quitar de la línea. Empresa Emplea * 1..* Contratante Empleado Trabajador salario Figura 11 Ejemplo de clase asociación II Asociaciones N-Arias En el caso de una asociación en la que participan más de dos clases, las clases se unen con una línea a un diamante central. Si se muestra multiplicidad en un rol, representa el número potencial de tuplas de instancias en la asociación cuando el resto de los N-1 valores están fijos. En la Figura 12 se ha impuesto la restricción de que un jugador no puede jugar en dos equipos distintos a lo largo de una temporada, porque la multiplicidad de Equipo es 1 en la asociación ternaria.

14 8 II.3 Diagramas de Estructura Estática Año Temporada * Equipo Juega 1 * Equipo Delantero Jugador goles en juego goles a balón parado goles de penalty Figura 12 Ejemplo de asociación ternaria II Navegabilidad En un extremo de una asociación se puede indicar la navegabilidad mediante una flecha. Significa que es posible "navegar" desde el objeto de la clase origen hasta el objeto de la clase destino. 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. II.3.4 Herencia La relación de herencia se representa mediante un triángulo en el extremo de la relación que corresponde a la clase más general o clase padre. Departamento Márketing Contabilidad Informática... Figura 13 Ejemplo de herencia 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. En el ejemplo de la Figura 13, sólo aparecen en el diagrama 3 tipos de departamentos, pero con los puntos suspensivos se indica que en el modelo completo (el formado por todos los diagramas) la

15 II.4 Diagrama de Casos de Uso 9 clase Departamento tiene subclases adicionales, como podrían ser Recursos Humanos y Producción. II.3.5 Elementos Derivados Persona {edad = fecha_actual fecha_de_nacimiento} nombre fecha_de_nacimiento /edad Figura 14 Ejemplo de atributo derivado 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. II.4 Diagrama de Casos de Uso Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. II.4.1 Elementos Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso. II Actores Un actor es una entidad externa al sistema que realiza algún tipo de interacción con el mismo. Se representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.). II 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. II Relaciones entre Casos de Uso Entre dos casos de uso puede haber las siguientes relaciones: Extiende: Cuando un caso de uso especializa a otro extendiendo su funcionalidad. Usa: Cuando un caso de uso utiliza a otro. Se representan como una línea que une a los dos casos de uso relacionados, con una flecha en forma de triángulo y con una etiqueta <<extiende>> o <<usa>> según sea el tipo de relación.

16 10 II.5 Diagramas de Interacción 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. En la Figura 15 se muestra un ejemplo de Diagrama de Casos de Uso para un cajero automático. Cajero Automático Realizar Reintegro Cambiar PIN <<extiende>> Cliente Obtener Últimos Movimientos y Saldo Realizar Reintegro con VISA Agregar Billetes Empleado de Sucursal Figura 15 Diagrama de Casos de Uso II.5 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. II.5.1 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. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren.

17 II.5 Diagramas de Interacción 11 :ClaseA :ClaseB mensaje1( ) mensaje2( ) mensaje3( ) II.5.2 Diagrama de Colaboración Figura 16 Diagrama de Secuencia 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. tratar_mensaje(mensaje) :Receptor_Mensajes 1a [mensaje.tipo = 1] : crear(mensaje) c:comando-1 1b [mensaje.tipo = 2] : crear(mensaje) c:comando-2 1.1: lanzar() c:comando Figura 17 Diagrama de Colaboración En cuanto a la representación, un Diagrama de Colaboración muestra a una serie de objetos con los enlaces entre los mismos, y con los mensajes que se intercambian dichos objetos. Los

18 12 II.6 Diagrama de Estados mensajes son flechas que van junto al enlace por el que circulan, y con el nombre del mensaje y los parámetros (si los tiene) entre paréntesis. Cada mensaje lleva un número de secuencia que denota cuál es el mensaje que le precede, excepto el mensaje que inicia el diagrama, que no lleva número de secuencia. Se pueden indicar alternativas con condiciones entre corchetes (por ejemplo 3 [condición_de_test] : nombre_de_método() ), tal y como aparece en el ejemplo de la Figura 17. También se puede mostrar el anidamiento de mensajes con números de secuencia como 2.1, que significa que el mensaje con número de secuencia 2 no acaba de ejecutarse hasta que no se han ejecutado todos los 2. x. II.6 Diagrama de Estados Un Diagrama de Estados muestra la secuencia de estados por los que pasa un caso de uso o un objeto a lo largo de su vida, indicando 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 estado se representa como una caja redondeada con el nombre del estado en su interior. Una transición se representa como una flecha desde el estado origen al estado destino. La caja de un estado puede tener 1 o 2 compartimentos. En el primer compartimento aparece el nombre del estado. El segundo compartimento es opcional, y en él pueden aparecer acciones de entrada, de salida y acciones internas. Una acción de entrada aparece en la forma entrada/acción_asociada donde acción_asociada es el nombre de la acción que se realiza al entrar en ese estado. Cada vez que se entra al estado por medio de una transición la acción de entrada se ejecuta. Una acción de salida aparece en la forma salida/acción_asociada. Cada vez que se sale del estado por una transición de salida la acción de salida se ejecuta. Una acción interna es una acción que se ejecuta cuando se recibe un determinado evento en ese estado, pero que no causa una transición a otro estado. Se indica en la forma nombre_de_evento/acción_asociada. [número.es_válido()] Descolgado Sin Marcar entrada / sonar_tono_de_llamada dígito(n) Marcado Parcial entrada/número.añadir_digito(n) dígito(n) Figura 18 Diagrama de Estados 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 (del caso de uso o 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

19 II.6 Diagrama de Estados 13 objeto no puede estar en esos estados, pero nos sirven para saber cuáles son las transiciones inicial y final(es).

20 14 III.1 Modelado Dinámico III Notación Avanzada UML III.1 Modelado Dinámico III.1.1 Diagramas De Actividades Vamos a recordar los diferentes modelos que sirven para representar el aspecto dinámico de un sistema: Diagramas de secuencia Diagramas de colaboración Diagramas de estados Diagramas de casos de uso Diagramas de actividades En este capítulo nos centraremos en los diagramas de actividades que sirven fundamentalmente para modelar el flujo de control entre actividades. La idea es generar una especie de diagrama Pert, 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. Por este motivo, en un diagrama de actividades aparecerán acciones y actividades correspondientes a distintas clases. Colaborando todas ellas para conseguir un mismo fin. Ejemplo: Hacer un pedido. III.1.2 Contenido del diagrama de actividades Básicamente un diagrama de actividades contiene: Estados de actividad Estados de acción Transiciones Objetos III 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:

21 III.1 Modelado Dinámico 15 Un estado que represente una acción es atómico, lo que significa que su ejecución se puede considerar instantánea y no puede ser interrumpida En la Figura 19, podemos ver ejemplos de estados de acción. Preparar Pedido Esto es un estado de acción con una acción simple Contador := Primero(lista)*7 Esto es un estado de acción con una expresión Figura 19 Estados de Acción En cambio un estado de actividad, sí puede descomponerse en más sub-actividades representadas a través de otros diagramas de actividades. Además estos estados sí pueden ser interrumpidos y tardan un cierto tiempo en completarse. En los estados de actividad podemos encontrar otros elementos adicionales como son: acciones de entrada (entry) y de salida (exit) del estado en cuestión, así como definición de submáquinas, como podemos ver en la Figura 20. ProcesarFactura(Fact) entry/sacarprimerafactura(fact) III Transiciones Figura 20 Estado de Actividad Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de acción. Esta transición se produce como resultado de la finalización del estado del que parte el arco dirigido que marca la transición. Como todo flujo de control debe empezar y terminar en algún momento, podemos indicar esto utilizando dos disparadores de inicio y fin tal y como queda reflejado en el ejemplo de la Figura 21. Estado inicial Activar Cajero Transición sin disparador Desactivar Cajero Estado de Parada Figura 21 Transiciones sin disparadores

22 16 III.1 Modelado Dinámico III Bifurcaciones Un flujo de control no tiene porqué ser siempre secuencial, puede presentar caminos alternativos. Para poder representar dichos caminos alternativos o bifurcación se utilizará como símbolo el rombo. Dicha bifurcación tendrá una transición de entrada y dos o más de salida. En cada transición de salida se colocará una expresión booleana que será evaluada una vez al llegar a la bifurcación, las guardas de la bifurcación han de ser excluyentes y contemplar todos los casos ya que de otro modo la ejecución del flujo de control quedaría interrumpida. Para poder cubrir todas las posibilidades se puede utilizar la palabra ELSE, para indicar una transición obligada a un determinado estado cuando el resto de guardas han fallado. En la Figura 22 podemos ver un ejemplo de bifurcación. Contabilizar Materiales [Materiales no disponibles] [Materiales disponibles] Hacer Pedido de Materiales Asignar Nuevas Tareas Figura 22 Bifurcación III 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. En la Figura 23 podemos ver cómo se representa gráficamente. División Unión III Calles Figura 23 División y unión 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

23 III.2 Modelado Físico De Un Sistema OO 17 calle representa a la parte de la organización responsable de las actividades que aparecen en esa calle. Gráficamente quedaría como se muestra en la Figura 24. Figura 24 Calles III.2 Modelado Físico De Un Sistema OO III.2.1 Componentes Los componentes pertenecen al mundo físico, es decir, representan un bloque de construcción al modelar aspectos físicos de un sistema. Una característica básica de un componente es que: debe definir una abstracción precisa con una interfaz bien definida, y permitiendo reemplazar fácilmente los componentes más viejos con otros más nuevos y compatibles. En UML todos los elementos físicos se modelan como componentes. UML proporciona una representación gráfica para estos como se puede ver en la Figura 25, en la que XXXX.dll, es el nombre del componente. XXXX.dll Figura 25 Representación de un componente Cada componente debe tener un nombre que lo distinga de los demás. Al igual que las clases los componentes pueden enriquecerse con compartimentos adicionales que muestran sus detalles, como se puede ver en la Figura 26.

24 18 III.2 Modelado Físico De Un Sistema OO Expresion.dll CalculaExpresionLógica CalculaExpresionAritm Figura 26 Representación extendida de un componente Vamos a ver con más detalle cuáles son los parecidos y las diferencias entre los componentes y las clases. PARECIDOS Ambos tienen nombre Ambos pueden realizar un conjunto de interfaces. Pueden participar en relaciones de dependencia, generalización y asociación. Ambos pueden anidarse Ambos pueden tener instancias Ambos pueden participar en interacciones Las Clases DIFERENCIAS Los Componentes Representan abstracciones lógicas Representan elementos físicos Es decir los componentes pueden estar en nodos y las clases no Pueden tener atributos y operacionesdirectamente accesibles. Sólo tienen operaciones y estas son alcanzables a través de la interfaz del componente. III 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. La relación entre un componente y sus interfaces se puede representar de dos maneras diferentes, de forma icónica como se indica en la Figura 27, y de forma expandida como se muestra en la Figura 28. Componente.java ObservadorDeImagen Imagen.java Figura 27 Componentes e interfaces, formato icónico

Desarrollo Orientado a Objetos con UML

Desarrollo Orientado a Objetos con UML Desarrollo Orientado a Objetos con UML Programación C.E.C.yT. Juan de Dios Bátíz Paredes IPN Índice I UML... I.1 Introducción... II NOTACIÓN UML... II.1 Modelos... II.2 Elementos Comunes a Todos los Diagramas...

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

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

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

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

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

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Diseño y Modelación de un Proyecto de Software Utilizando el lenguaje UML

Diseño y Modelación de un Proyecto de Software Utilizando el lenguaje UML Diseño y Modelación de un Proyecto de Software Utilizando el lenguaje UML INTRODUCCION Desde los inicios de la informática se han estado utilizando distintas formas de representar los diseños de una manera

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

Diseño lógico de sistemas aplicando el lenguaje de modelado unificado

Diseño lógico de sistemas aplicando el lenguaje de modelado unificado Diseño lógico de sistemas aplicando el lenguaje de modelado unificado No. De Registro CGPI: 20061221. Director del proyecto: Roberto De Luna Caballero. Profesores participantes: M. en C Fabiola Ocampo

Más detalles

Ejercicio Guiado de Análisis y Diseño Orientado a Objetos. Ejemplo: CAJERO AUTOMÁTICO

Ejercicio Guiado de Análisis y Diseño Orientado a Objetos. Ejemplo: CAJERO AUTOMÁTICO Ejercicio Guiado de Análisis y Diseño Orientado a Objetos Ejemplo: CAJERO AUTOMÁTICO El siguiente ejercicio muestra las diferentes actividades que se realizan dentro del desarrollo de un producto software

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

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

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

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

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

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

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

2.- Diseño del comportamiento: Diagrama de actividades. Mª Antonia Zapata

2.- Diseño del comportamiento: Diagrama de actividades. Mª Antonia Zapata 2.- Diseño del comportamiento: Diagrama de actividades Mª Antonia Zapata Introducción Los diagramas de actividades sirven para representar el comportamiento dinámico de un sistema haciendo hincapié en

Más detalles

DIAGRAMA DE CLASES EN UML

DIAGRAMA DE CLASES EN UML DIAGRAMA DE CLASES EN UML Mg. Juan José Flores Cueto jflores@usmp.edu.pe Ing. Carmen Bertolotti Zuñiga cbertolotti@usmp.edu.pe INTRODUCCIÓN UML (Unified Modeling Language) es un lenguaje que permite modelar,

Más detalles

PROCESO UNIFICADO CAPTURA DE REQUISITOS

PROCESO UNIFICADO CAPTURA DE REQUISITOS PROCESO UNIFICADO CAPTURA DE REQUISITOS El proceso unificado de desarrollo, Ivar Jacobson, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999 The unified software development process, Ivar Jacobson,

Más detalles

Ejemplo: agencia de viajes por internet

Ejemplo: agencia de viajes por internet Introducción Modelado de casos de uso Propósito y definición Casos de uso y extracción de requisitos Carácter hipotético de los casos de uso El modelo de casos de uso Notación. Actores y casos de uso.

Más detalles

6.6 DISEÑO. [Proceso]

6.6 DISEÑO. [Proceso] 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

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS ANÁLISIS Y DISEÑO DE SISTEMAS Clase XVIII: Modelo Dinámico Diagramas de Actividades Primer Cuatrimestre 2013 Diagrama de Actividades (DA) Un grafo o diagrama de actividad (DA) es un tipo especial de máquina

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

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

Modelado Avanzado con Casos de Uso. Diseño de Software Avanzado Departamento de Informática

Modelado Avanzado con Casos de Uso. Diseño de Software Avanzado Departamento de Informática Modelado Avanzado con Casos de Uso Especificación Gráfica de Casos de Uso Una simple secuencia de acciones no puede describir adecuadamente la riqueza de situaciones que se pueden presentar en un caso

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

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

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

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

ICONIX. Notas del método con ampliaciones y mejoras

ICONIX. Notas del método con ampliaciones y mejoras ICONIX Notas del método con ampliaciones y mejoras Juan Manuel Fernández Peña y María de los Ángeles Sumano López Colaboración de Josué Andrade Mirós Octubre de 2004 Método ICONIX Referencia El método

Más detalles

Metodologías para generación de Sistemas Orientados a Objetos

Metodologías para generación de Sistemas Orientados a Objetos Metodologías para generación de Sistemas Orientados a Objetos Análisis y Diseño (Tecnologías) Orientado a Objetos Dr. Leopoldo Altamirano Robles 22 septiembre, 2003 Alicia Morales Reyes Alma Rosa Rugerio

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

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

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

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar MODELADO DE OBJETOS Bibiana ROSSI, Paola BRITOS y Ramón GARCIA MARTINEZ, CAPIS - Centro de Actualizacion Permanente en Ingeniería de Software Escuela de Posgrado. ITBA. 0. INTRODUCCION {brossi,pbritos,rgm}@itba.edu.ar

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

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

Planificación y Control de Proyectos de Software mediante MS Project

Planificación y Control de Proyectos de Software mediante MS Project Práctica 2 Planificación y Control de Proyectos de Software mediante MS Project E n esta práctica vamos a introducirnos en la Planificación y Control de Proyectos de Software mediante herramientas informáticas

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

PUD: Proceso de Desarrollo Unificado

PUD: Proceso de Desarrollo Unificado PUD: Proceso de Desarrollo Unificado 1 1998 Genealogía del PUD Rational Unified Process 5.0 1997 Rational Objectory Process 4.1 UML 1996 Rational Objectory Process 4.0 1995 Método Ericsson Rational Approach

Más detalles

IWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1

IWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1 IWG-101: Introducción a la Ingeniería Departamento de Informática, UTFSM 1 Introducción a UML Historia Potencialidades Diagramas soportados UML en el proceso de desarrollo de SW. Introducción a UML Necesidad

Más detalles

El proceso unificado en pocas palabras

El proceso unificado en pocas palabras El Proceso Unificado de Desarrollo de Software Ivar Jacobson Grady Booch James Rumbaugh Addison Wesley Resumen Capítulo 1. El proceso unificado: dirigido por casos de uso, centrado en la arquitectura,

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

El Proceso Unificado Rational para el Desarrollo de Software.

El Proceso Unificado Rational para el Desarrollo de Software. Instituto de Electrónica y Computación El Proceso Unificado Rational para el Desarrollo de Software. Carlos Alberto Fernández y Fernández Huajuapan de León, Oaxaca 26 de octubre de 2000 Objetivo Proporcionar

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

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Ó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

TEMA 1.-Programación orientada a objetos (POO) Objetivo

TEMA 1.-Programación orientada a objetos (POO) Objetivo CURSO DE UML Dotar al alumno de los fundamentos de la programación orientada a objetos (POO, a partir de ahora), definir las características básicas del lenguaje de modelado unificado (Unified Modeling

Más detalles

INGENIERÍA DEL SOFTWARE I Tema 8. Contexto y Requisitos del Sistema (en desarrollo OO)

INGENIERÍA DEL SOFTWARE I Tema 8. Contexto y Requisitos del Sistema (en desarrollo OO) INGENIERÍA DEL SOFTWARE I Tema 8 Contexto y Requisitos del Sistema (en desarrollo OO) Univ. Cantabria Fac. de Ciencias Francisco Ruiz y Patricia López Objetivos del Tema Conocer en detalle la técnica 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

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R índice Módulo A Unidad didáctica 1: Introducción a las Bases de Datos Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos 3 19 Módulo B Unidad didáctica 1: Fase de análisis de requisitos Modelo

Más detalles

Bienvenidos a la presentación: Introducción a conceptos básicos de programación.

Bienvenidos a la presentación: Introducción a conceptos básicos de programación. Bienvenidos a la presentación: Introducción a conceptos básicos de programación. 1 Los programas de computadora son una serie de instrucciones que le dicen a una computadora qué hacer exactamente. Los

Más detalles

INGENIERÍA DEL SOFTWARE I Tema 13. Arquitectura Física del Sistema (en desarrollo OO) Univ. Cantabria Fac. de Ciencias Francisco Ruiz

INGENIERÍA DEL SOFTWARE I Tema 13. Arquitectura Física del Sistema (en desarrollo OO) Univ. Cantabria Fac. de Ciencias Francisco Ruiz INGENIERÍA DEL SOFTWARE I Tema 13 Arquitectura Física del Sistema (en desarrollo OO) Univ. Cantabria Fac. de Ciencias Francisco Ruiz Objetivos del Tema Presentar los conceptos básicos de UML 2 para el

Más detalles

INGENIERÍA DEL SOFTWARE I Tema 11. Arquitectura Física del Sistema (en desarrollo OO) Univ. Cantabria Fac. de Ciencias Carlos Blanco, Francisco Ruiz

INGENIERÍA DEL SOFTWARE I Tema 11. Arquitectura Física del Sistema (en desarrollo OO) Univ. Cantabria Fac. de Ciencias Carlos Blanco, Francisco Ruiz INGENIERÍA DEL SOFTWARE I Tema 11 Arquitectura Física del Sistema (en desarrollo OO) Univ. Cantabria Fac. de Ciencias Carlos Blanco, Francisco Ruiz Objetivos del Tema Presentar los conceptos básicos de

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

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

Más detalles

INGENIERÍA DEL SOFTWARE I Tema 5 Contexto y Requisitos del Sistema (Modelado en desarrollo OO)

INGENIERÍA DEL SOFTWARE I Tema 5 Contexto y Requisitos del Sistema (Modelado en desarrollo OO) INGENIERÍA DEL SOFTWARE I Tema 5 Contexto y Requisitos del Sistema (Modelado en desarrollo OO) Universidad de Cantabria Facultad de Ciencias Patricia López y Francisco Ruiz Objetivos del Tema Objetivos:

Más detalles

IVista: es la interfaz con la que el Presentador se comunica con la vista.

IVista: es la interfaz con la que el Presentador se comunica con la vista. Capítulo 3 MODELO DE DISEÑO 3.1 Arquitectura Modelo-Vista-Presentador La arquitectura Modelo-Vista-Presentador (MVP) [11] separa el modelo, la presentación y las acciones basadas en la interacción con

Más detalles

TEMA 14. Modelos de representación de diagramas

TEMA 14. Modelos de representación de diagramas TEMA 14. Modelos de representación de diagramas Un diagrama es un dibujo en el que se muestran las relaciones entre las diferentes partes que componen un conjunto o sistema. También se puede entender como

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

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

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

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje

Más detalles

GANTT, PERT y CPM. Figura 5.3: Carta GANTT 3.

GANTT, PERT y CPM. Figura 5.3: Carta GANTT 3. GANTT, PERT y CPM Características Conseguir una buena programación es un reto, no obstante es razonable y alcanzable. Ella debe tener el compromiso del equipo al completo, para lo cual se recomienda que

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

UML. UML significa Lenguaje Unificado de Modelado UML combina lo mejor de:

UML. UML significa Lenguaje Unificado de Modelado UML combina lo mejor de: UML UML significa Lenguaje Unificado de Modelado UML combina lo mejor de: Conceptos de modelado de datos (diagramas entidad-relación) Modelado de negocios (flujos de trabajo) Modelado de objetos Modelado

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

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

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

DESARROLLO DE PROYECTOS DE SOFTWARE

DESARROLLO DE PROYECTOS DE SOFTWARE SECRETARÍA DE EDUCACIÓN SUBSECRETARÍA DE EDUCACIÓN MEDIA SUPERIOR Y SUPERIOR TECNOLÓGICO DE ESTUDIOS SUPERIORES DEL ORIENTE DEL ESTADO DE MÉXICO DIVISIÓN DE INGENIERÍA EN SISTEMAS COMPUTACIONALES CUADERNILLO

Más detalles

Análisis y diseño de una aplicación control de inventarios de una empresa lechera. HOLANDESA

Análisis y diseño de una aplicación control de inventarios de una empresa lechera. HOLANDESA Análisis y diseño de una aplicación control de inventarios de una empresa lechera. HOLANDESA MEMORIA Trabajo Final de Carrera Titulación Ingeniería Técnica en Informática de Sistemas Semestre Área Ingeniería

Más detalles

PROGRAMACION ORIENTADA A OBJETOS CON PHP

PROGRAMACION ORIENTADA A OBJETOS CON PHP PROGRAMACION ORIENTADA A OBJETOS CON PHP COMO SE DEFINE EN PHP La programación orientada a objetos es una metodología de programación avanzada y bastante extendida, en la que los sistemas se modelan creando

Más detalles

CAPÍTULO 1. MARCO TEÓRICO

CAPÍTULO 1. MARCO TEÓRICO CAPÍTULO 1. MARCO TEÓRICO Capítulo 1. Marco teórico 1.1 Ingeniería Web (IWeb) Con el desarrollo de Internet, la mayoría de los proyectos y sistemas están enfocados para las aplicaciones basadas en la Web

Más detalles

Modelos de Desarrollo de Programas

Modelos de Desarrollo de Programas Modelos de Desarrollo Orientados a Objetos Adriana Castro Bonenfant Curso 2009/2010 Índice 1. Ciclo de vida del software 3 1.1. Introducción.................................... 3 1.2. Objetivos.....................................

Más detalles

ETIQUETA DISEÑO DE PÁGINA

ETIQUETA DISEÑO DE PÁGINA ETIQUETA DISEÑO DE PÁGINA Es la tercera etiqueta de Excel 2007, agrupa las herramientas de temas 10, configuración de pagina, ajustes del área de impresión, opciones de la hoja (cuadriculas y encabezados),

Más detalles

Weitzenfeld: Capítulo 4 1

Weitzenfeld: Capítulo 4 1 Weitzenfeld: Capítulo 4 Parte II Modelado y Programación Orientada a Objetos En esta segunda parte se describirá la programación orientada a objetos desde dos perspectivas distintas. La primera es el modelado

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

Técnicas y Prácticas

Técnicas y Prácticas Técnicas y Prácticas ÍNDICE INTRODUCCIÓN... 3 TÉCNICAS DE DESARROLLO... 4 ANÁLISIS COSTE/BENEFICIO... 4 CASOS DE USO... 8 DIAGRAMA DE CLASES... 13 DIAGRAMA DE COMPONENTES... 19 DIAGRAMA DE DESCOMPOSICIÓN...

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

SIGPRE Sistema de Gestión Presupuestaria

SIGPRE Sistema de Gestión Presupuestaria SIGPRE Sistema de Gestión Presupuestaria Documento de Arquitectura UTN Histórico de Revisiones Fecha Versión Descripción Autor 11/17/2009 1.0 Borrador de la arquitectura Roberto López Hinojosa 12/14/2009

Más detalles

El modelo de casos de uso. Ingeniería de la Programación

El modelo de casos de uso. Ingeniería de la Programación El modelo de casos de uso Ingeniería de la Programación Prácticas cas 1 Contenidos Introducción RF y RNF Introducción al modelo de RF de UML. Actores y Casos de Uso Modelo de casos de uso Diagrama de contexto

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

Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos

Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos 1. Introducción Curso académico 2009-2010 La práctica de Integración de Sistemas consiste en el diseño

Más detalles

2.1 Ingeniería de Software

2.1 Ingeniería de Software Capítulo 2 Marco Teórico Se pretende desarrollar un software que pueda ser aplicado como una herramienta útil para la administración de una empresa. Es necesario tener en cuenta que, en todo desarrollo

Más detalles

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN Diagrama de Gantt Fue desarrollada por Henry L. Gantt, durante la primera guerra mundial. Con estas graficas Gantt procuro resolver el problema

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

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

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

Tema 6º: Diseño Orientado a Objetos

Tema 6º: Diseño Orientado a Objetos Tema 6º: Diseño Orientado a Objetos Diseño preliminar y Diseño detallado Modelado de la Arquitectura del Sistema Abstracciones y mecanismos clave Elementos básicos del Diseño Orientado a Objetos Diagramas

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

Modelado de objetos con UML

Modelado de objetos con UML Modelado de objetos con UML José Vicente Núñez Zuleta (jose@eud.com, josevnz@yahoo.com) Líder de desarrollo para El Diario El Universal División de Nuevos Medios Puntos a tratar Qué es UML? Tipos de diagramas.

Más detalles