Índice.

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

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

Transcripción

1 Módulo 2 UML

2 Í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: Secuencia Diagramas de interacción: Colaboracion Diagramas de comportamiento: Estado Diagramas de comportamiento: Actividad Diagramas de implementación: Componentes Diagramas de implementación: Despliegue

3 Introducción UML A principios de los 90 existían muchos métodos de análisis y diseño Orientado a Objetos. Estos métodos, se basaban en los mismos conceptos pero con distinta notación lo cual creaba mucha confusión. En 1994 Grady Booch y Jim Rumbaugh de Rational Software Corporation decidieron unificar sus trabajos en un método único: el método unificado (The Unified Method) cuya primera versión fue presentada en Octubre de Un año después se les unió Jacobson y el método unificado se transformo en UML (The Unified Modeling Method).

4 Introducción UML Objetivos Al finalizar este módulo deberías ser capaz de: Conocer las características básicas del lenguaje modelado unificado (UML) y aplicarlas al análisis y diseño Orientado a Objetos Analizar los requisitos del sistema para determinar los casos de uso y el modelo de dominio Crear los principales diagramas para modelar una aplicación tanto desde el punto de vista dinámico como estático

5 El proceso de desarrollo software El proceso de desarrollo de software es un método de organizar las actividades relacionadas con la creación, presentación y mantenimiento de los sistemas software. En él existen cinco actividades fundamentales comunes a todos los procesos software: planificación y selección del software análisis del software diseño del software implantación y operación del software mantenimiento del software

6 El proceso de desarrollo software Modelos El modelo captura una vista de un sistema del mundo real. Es por tanto una abstracción de dicho sistema, considerando un cierto propósito. Así el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle Estos modelos se visualizan a través de un conjunto de diagramas

7 Lenguaje Unificado de Modelado (UML) Qué es UML? Cuando hablamos del lenguaje unificado de modelado o UML, nos estamos refiriendo a un lenguaje de propósito general para el modelado orientado a objetos que combina notaciones de los modelados OO, de datos, componentes y workflows. Su objetivo es ser una notación estándar Este lenguaje define una notación que se expresa como diagramas que sirven para representar modelos, subsistemas o parte de ellos. Además, define una estructura para ir del análisis al diseño y del diseño a la implementación.

8 Lenguaje Unificado de Modelado (UML) Qué NO es UML? Antes de seguir avanzando, es importante tener en cuenta que el estándar UML no define un proceso de desarrollo específico, sólo se trata de una notación En otras palabras, se puede aplicar en el desarrollo de software para dar soporte a una metodología (como RUP), pero no especifica en sí mismo la metodología o proceso a usar Asimismo, al no ser un método de desarrollo, es independiente del ciclo de desarrollo.

9 Lenguaje Unificado de Modelado (UML) Qué ventajas e inconvenientes tiene UML? Los principales inconvenientes que nos podemos encontrar en el lenguaje unificado son: No cubre todas las necesidades de especificación de un proyecto software Falta integración con respecto a otras técnicas, tales como patrones de diseño, interfaces de usuario, documentación etc. Las principales ventajas que aporta el lenguaje UML son: Permite conectarse a lenguajes de programación Permite documentar todos los artefactos de un proceso de desarrollo Es un estándar que, además será el predominante en los próximos años

10 Diagramas UML El lenguaje UML cuenta con varios tipos de diagramas que reflejan diferentes aspectos de las entidades representadas Estos diagramas son los siguientes: Diagramas de casos de uso: Acciones del sistema desde el punto de vista del usuario Diagramas estructurales: Diagramas de clases: Para modelar la estructura estática de las clases del sistema Diagramas de Objetos: Modelan instancias de los elementos contenidos en el diagrama Diagramas de interacción: Diagramas de secuencias: Para modelar el paso de mensajes entre objetos Diagramas de colaboración: Para modelar interacciones entre objetos

11 Diagramas UML Diagramas de comportamiento Diagrama de estado: Para modelar el comportamiento de los objetos del sistema Diagrama de actividad: Para modelar el comportamiento de los casos de uso, objetos u operaciones Diagramas de implementación: Diagrama de componentes: Para modelar componentes Diagrama de despliegue: Para modelar la distribución del sistema

12 Identificación de los requisitos Diagramas de casos de uso Los casos de uso son una técnica de recolección y especificación de requisitos que ayuda a obtener los requerimientos desde el punto de vista del usuario En un diagrama de casos de uso, podemos distinguir dos elementos, como los actores y los casos de uso Los Actores : Son los Roles que juega un usuario con respecto al sistema. Un usuario puede jugar diferentes roles e intervenir en varios casos de uso. A su vez, en un mismo caso de uso, puede intervenir diferentes actores Los Casos de Uso: Son iteraciones típicas entre los usuarios y el sistema. Es decir, un caso de uso es una operación o tareas específicas que se realizan tras una orden de algún agente externo, originada por una petición de un actor, o bien desde la innovación de otro caso de uso Los casos de uso se determinan observando y precisando, actor por actor, las secuencias de interacción y los escenarios desde el punto de vista del usuario

13 Identificación de los requisitos Diagramas de casos de uso Con la ayuda de estos dos elementos, vamos a crear el diagrama de caso de uso, para lo cual deberemos seguir tres pasos: Encontrar actores Encontrar casos de uso Encontrar relaciones entre actores y casos de uso

14 Identificación de los requisitos Diagramas de casos de uso Tanto si el cliente quiere realizar un reintegro como si quiere realizar un integro, tiene una tarea común a ambos

15 Identificación de los requisitos Diagramas de casos de uso El cliente además también podría realizar un reintegro con VISA, lo que sería similar a realizar el reintegro pero con sus peculiaridades, con lo cual extiende de Realizar reintegro

16 Identificación de los requisitos Diagramas de casos de uso Podría darse el caso también de que el cliente realizara una transferencia por internet, para lo cual debería identificarse

17 Diagramas estructurales Diagrama de clases En líneas generales, en este tipo de modelado estructural se describen los tipos de objetos de un sistema y las relaciones estáticas que existen entre ellos Para detallar este tipo de diagrama, se usan muchos de los otros diagramas, incluso el diagrama de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones tan útiles en el diagrama de clase Es el diagrama principal para el análisis y el diseño en orientación a objetos Muestra las relaciones estructurales y estáticas entre las clases que se irán refinando durante todo el proceso de desarrollo Los elementos de los diagramas de clases son: Clases: Formadas por atributos y operaciones Relaciones: Herencia, asociación, agregación y dependencia

18 Diagramas estructurales Diagrama de clases Una clase es una descripción (plantilla) de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Así, un objeto es una instancia de una clase Cada clase se representa en el diagrama como un rectángulo con tres compartimentos : Nombre de la clase Atributos: características de los objetos que pueden tomar valores. Su sintaxis es: visibilidad nombre [multiplicidad] : tipo = valor-inicial {propiedades} Métodos: definen la manera en la que los objetos pueden interactuar con el entorno, es decir, lo que una clase puede realizar. Su sintaxis es: visibilidad nombre (parámetros) : tipo-devuelto {propiedades}

19 Diagramas estructurales Diagrama de clases: Ejemplo

20 Diagramas estructurales Diagrama de clases: Privacidad En la visibilidad o encapsulación de los atributos y los métodos existen tres niveles : public (+): indica que el atributo/método será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos los lados private (-): indica que el atributo/método sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar ) protected (#): indica que el atributo/método no será accesible desde fuera de la clase, pero si podrá ser accedido por métodos de la clase además de las subclases que se deriven. Más adelante, cuando veamos el término herencia, veremos más al detalle este aspecto

21 Diagramas estructurales Diagrama de clases: Relaciones entre clases Cardinalidad: Indica el grado y nivel de dependencia. Se anotan en cada extremo de la relación y éstas pueden ser: Exactamente uno: 1,(1) Uno o muchos: 1..*(1..n)(al menos uno) 0 o muchos: 0 * (0.. N), * Número fijo: m (m denota el número) Número variable, pero limitado, por ejemplo, por lo menos 2, pero no más de 6 : 2..6,(2,6)

22 Diagramas estructurales Diagrama de clases: Relaciones entre clases (II) Asociación: Permite asociar objetos que colaboran entre sí expresando una conexión bidireccional entre ellos Cada extremo de la asociación también tiene un valor de multiplicidad o cardinalidad, que indica cuantos objetivos de ese lado de la asociación están relacionados con un objeto del extremo contrario

23 Diagramas estructurales Diagrama de clases: Relaciones entre clases (III) Agregación: Representa una relación parte de entre objetos, de tal modo que cuando los objetos de un todo están compuestos por la unión de los objetos de otra parte existe una agregación

24 Diagramas estructurales Diagrama de clases: Relaciones entre clases (IV) Composición: Son asociaciones que representan agregaciones muy fuertes. Las composiciones forman relaciones completas, pero dichas relaciones son tan fuertes que las partes no pueden existir por sí mismas. Únicamente existen como parte del conjunto, y si este es destruido las partes también lo son Por ejemplo: Un detalle es parte de una compra, es una relación de agregación más fuerte que la del ejemplo anterior. Por lo tanto, podemos decir que un detalle no puede existir si no existe una compra, esto es, se trata de una relación de composición.

25 Diagramas estructurales Diagrama de clases: Relaciones entre clases (V) Generalización o herencia: Es una asociación entre una clase más general (superclase o clase padre) y una clase más especifica (subclase o clase hija) La clase hija, además de poseer sus propios atributos, hereda los métodos y atributos visibles de la clase padre (public y protected)

26 Diagramas estructurales Diagrama de clases: Relaciones entre clases (VI) Dependencia: Tipo de relación particular donde el cambio en una clase afecta a la otra Por ejemplo: Una tarjeta depende de una cuenta, con lo cual, cualquier cambio en la tarjeta afectará a la cuenta

27 Diagramas estructurales Diagrama de clases: Abstracción Además de la clase y las relaciones de clase que componen los diagramas de clase, existen otros elementos que conviene tener en cuenta, como son: 1. Clase abstracta: es una clase que posee métodos abstractos (sin implementación) y, por tanto, no puede ser instanciada. Basta con que un método sea abstracto para que la clase también lo sea. La única forma de utilizarla es definiendo subclases que implementen los métodos abstractos definidos Para denotar una clase abstracta, se emplea el nombre de la clase y de los métodos con letra "itálica". Ejemplo:

28 Diagramas estructurales Diagrama de clases: Interface 2. Interface: es una clase completamente abstracta que se representa mediante una caja con el nombre y operaciones, y el estereotipo «interface» o mediante un círculo pequeño con el nombre de la interfaz debajo Ejemplo: Interface

29 Diagramas estructurales Diagrama de clases: Polimorfismo 3. Polimorfismo: es la capacidad que tienen los objetos de una clase de responder al mismo mensaje o evento en función de los parámetros utilizados durante su invocación. Así un objeto polimórfico es una entidad que puede contener valores de diferentes tipos durante la ejecución de un programa En otras palabras representa la posibilidad de desencadenar operaciones distintas en respuesta a un mismo mensaje Casa subclase hereda las operaciones pero puede modificar localmente el comportamiento de estas Ejemplo:

30 Diagramas estructurales Diagrama de clases: Paquetes 4. Paquetes: los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema) Hay que tener en cuenta que un paquete puede contener otros paquetes, sin límite de anidamiento, pero cada elemento pertenece a (está definido en) un solo paquete y cada uno de ellos puede contener más de una clase Una clase de un paquete puede aparecer en otro paquete por la importación a través de una relación de dependencia entre paquetes. Estas relaciones entre paquetes son iguales que las relaciones entre clases Ejemplo:

31 Diagramas estructurales Diagrama de clases: Ejemplo

32 Diagramas de interacción Diagramas de secuencia Estos diagramas de secuencia, al igual que los diagramas de colaboración que veremos en este mismo apartado, pertenecen al grupo que podíamos denominar diagramas de interacción, los cuales describen como los objetos colaboran entre sí para realizar cierta actividad Los diagramas de secuencia muestran en detalle un caso de uso del negocio, del sistema o un determinado escenario para cada caso de uso Su objetivo es describir el comportamiento dinámico del sistema Además, muestran el intercambio de mensajes en un momento dado, poniendo especial énfasis en el orden y momento que se envían los mensajes a los objetos

33 Diagramas de interacción Diagramas de secuencia (II) Los diagramas de secuencia se componen de 3 elementos: Línea de vida Mensajes Activación

34 Diagramas de interacción Diagramas de secuencia (III) Línea de vida: La línea de vida de un objeto representa la vida del mismo durante la interacción En un diagrama de secuencia un objeto se representa con una línea vertical punteada con un rectángulo de encabezado que contiene el nombre del objeto y el de su clase, en un formato nombreobjeto:nombreclase. El inicio de la línea de vida se corresponde con el momento de creación del objeto. Si un objeto es destruido antes de terminar el diagrama se representa con un aspa

35 Diagramas de interacción Diagramas de secuencia (IV) Mensajes: El envío de mensajes entre los objetos se denota mediante una flecha que va desde el objeto que emite el mensaje hacia el objeto que lo ejecuta A la flecha se le asocia una etiqueta con el mensaje y los argumentos: También es posible añadir a los mensajes, condiciones e iteraciones: La condición se representa mediante una condición booleana entre corchetes; de esa manera el mensaje será enviado si la condición es cierta. La iteración se representa mediante un asterisco y una expresión entre corchetes indicando el número de veces que se ejecuta. Un objeto puede enviar mensajes a si mismo

36 Diagramas de interacción Diagramas de secuencia (V) Activación: Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando alguna operación, bien sea por si mismo o por medio de alguno de sus atributos Este elemento se representa mediante un rectángulo superpuesto a la línea de vida de un objeto Su tamaño depende de la duración de la acción realizada por el objeto La parte superior corresponde al inicio de la acción y la parte inferior indica la terminación

37 Diagramas de interacción Diagramas de secuencia (VI) Cuando el cliente llega al cajero, el cliente introduce la tarjeta y el cajero le solicitará el pin. Una vez que introduce el pin, el cajero le pedirá que introduzca la operación a realizar. En ese instante, el cajero accederá a la cuenta donde consultará el saldo y se lo enviará al cajero para que se lo muestre al cliente

38 Diagramas de interacción Diagramas de colaboración Los diagramas de colaboración muestran las iteraciones que ocurren entre los objetos que participan en una situación determinada Es más o menos la misma información que la mostrada por los diagramas de secuencia, pero los diagramas de colaboración fijan el interés en las relaciones entre los objetos y su topología Estos diagramas se componen de tres elementos: Objetos Mensajes Enlaces

39 Diagramas de interacción Diagramas de colaboración (II) Objetos: Se representan mediante un rectángulo en cuyo interior se coloca el nombre del objeto y el nombre de la clase a la que pertenece (nombre del objeto:nombreclase) Mensajes: Se representa mediante una pequeña flecha asociado a un enlace La dirección de la flecha indica el sentido del mensaje Es necesario indicar delante del mensaje su numero dentro de la secuencia de mensajes que se produce También pueden contener condiciones e iteraciones al igual que en los diagramas de secuencia Enlace: Es una instancia de una asociación en un diagrama de clases y se representa con una línea continua que une dos objetos

40 Diagramas de interacción Diagramas de colaboración (III)

41 Diagramas de comportamiento Diagramas de estado Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación, junto con los cambios que permiten pasar de un estado a otro Estos diagramas se componen de tres elementos: Un estado es una condición durante la vida de un objeto, de forma que cuando dicha condición se satisface se lleva a cabo alguna acción o se espera por un evento. Los estados se representan mediante un rectángulo con bordes redondeados. Entre ellos podemos distinguir dos tipos especiales: inicio y fin. La razón por la que son especiales es que no hay ningún evento que pueda devolver a un objeto a su estado de inicio, y de la misma forma, no hay ningún evento que pueda sacar a un objeto de su estado de fin. Una transición de un estado A a un estado B, se produce cuando se origina el evento asociado y se satisface la condición especificada, en cuyo caso se ejecuta la acción de salida A, la acción de entrada de B y la acción asociada a la transición

42 Diagramas de comportamiento Diagramas de estado (II) Evento: Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta ocurrencia puede ser: Condición que toma el valor verdadero o falso (se representa poniendo la condición entre corchetes) Recepción de una señal de otro objeto en el modelo Recepción de un mensaje Paso de cierto periodo de tiempo, después de entrar al estado, o de cierta hora y fecha particular

43 Diagramas de comportamiento Diagramas de estado (III) Los posibles estados del cajero son: Libre Ocupado Fuera de servicio En mantenimiento Por ejemplo, si el cajero está libre y alguien (un cliente) lo ocupa, el cajero pasará al estado ocupado.

44 Diagramas de comportamiento Diagramas de actividad Los diagramas de actividad describen la secuencia de las actividades en un sistema Son una forma especial de los diagramas de estado, que únicamente (o mayormente) contienen actividades Puede dar un detalle a un caso de uso, un objeto o un mensaje de un objeto Estos diagramas sirven para representar transiciones internas, sin hacer mucho énfasis en transiciones o eventos externos. Generalmente modelan los pasos de un algoritmo y pueden especificar: Un método Un caso de uso Un proceso de negocio (workflow)

45 Diagramas de comportamiento Diagramas de actividad (II) Estos diagramas se componen de tres elementos : Estado de acción:rrepresenta un estado con acción interna con, por lo menos, una transición que identifica la culminación de la acción (por medio de un evento implícito) No deben tener transiciones internas ni transiciones basadas en eventos (si este es el caso, se representan en un diagrama de estados) Los estados de acción permiten modelar un paso dentro del algoritmo y se representan por un rectángulo con bordes redondeados Transiciones: Las flechas entre estados representan transiciones con evento implícito. Las transiciones pueden tener una condición en el caso de decisiones Decisiones: Se representa mediante un rombo al cual llega la transición del estado inicial y del cual salen las múltiples transiciones de los estados finales.

46 Diagramas de comportamiento Diagramas de actividad (III) En el siguiente ejemplo de diagrama de actividad, cuando el cliente introduce la tarjeta, puede ocurrir que esta esté operativa o no Si no lo está finaliza la actividad En cambio, si la tarjeta está operativa el cliente deberá introducir el pin Si este es introducido erróneamente, aquí finaliza la actividad, pero si es válido, el cliente podrá realizar la operación deseada.

47 Diagramas de implementación Diagramas de componentes e implementación Tanto los diagramas de componentes como los diagramas de despliegue pueden encuadrarse dentro de los diagramas de implementación Los diagramas de implementación residen en los nodos del sistema y se trata de una colección de componentes y la implementación de los subsistemas que los contienen Asimismo modelan artefactos tales como ejecutables, bibliotecas, tablas, ficheros. En líneas generales, podemos decir que representan el empaquetamiento físico de elementos lógicos tales clases, interfaces, etc. Ahora que ya conocemos lo que son los diagramas de implementación, vamos a descubrir los dos tipos que nos podemos encontrar comenzando por los diagramas de componentes. Estos muestran la organización de los componentes software que puede ser código fuente, binario, ejecutable o una librería con una interfaz definida. Esta interfaz establece las operaciones externas de un componente.

48 Diagramas de implementación Diagramas de componentes Muestran la organización de los componentes software que puede ser código fuente, binario, ejecutable o una librería con una interfaz definida Esta interfaz establece las operaciones externas de un componente Los componentes son paquetes estereotipados en «subsistemas» para incorporar la noción de biblioteca de compilación, pudiendo agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación Así pues, en los diagramas de componentes se representan las relaciones de dependencia entre componentes o entre un componente y una interfaz de otro

49 Diagramas de implementación Diagramas de componentes (II) Formados por los siguientes elementos: Componente: Se representa con un rectángulo con dos pequeños rectángulos superpuesto perpendicularmente en el lado izquierdo Para distinguir los tipos de componentes se les puede asignar un estereotipo cuyo nombre estará dentro del símbolo << >> Relación de dependencia: Se representa mediante una línea discontinua con una flecha que apunta al componente o interfaz que provee del servicio o facilidad del otro. Puede tener un estereotipo que se coloca junto a la línea Interfaz: Se representa con un pequeño círculo situado junto al componente que lo implementa y unido a él por una línea continua La interfaz puede tener un nombre que se escribe junto al circulo Un componente puede proporcionar más de una interfaz

50 Diagramas de implementación Diagramas de despliegue Los diagramas de despliegue muestran las relaciones entre los componentes hardware y software en el sistema final, es decir, la configuración de los elementos de procesamiento en tiempo de ejecución y los componentes software (procesos y objetos que se ejecutan en ellos) En estos diagramas se representan dos tipos de elementos, nodos y conexiones, así como la distribución de componentes del sistema de información con respecto a la partición física del sistema Los componentes se ejecutan en nodos Un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional que puede tener memoria y capacidad de procesamiento Representan el despliegue físico de los componentes. Además cada nodo puede contener instancias de componentes.

51 Diagramas de implementación Diagramas de despliegue (II) A la hora de representarse, contamos con: nodos: Representados por cubos conexiones: Como líneas de comunicaciones Se reflejan los protocolos de comunicaciones Se refleja la cantidad de nodos existentes El diagrama de despliegue muestra la configuración de los nodos que participan en la ejecución y de los componentes que residen en los nodos. Incluye nodos y arcos que representa conexiones físicas entre nodos <<cliente>> <<Interface>> Terminal de de Cajero cajero <<TCP/IP>> <<Servidor>> Bases de datos <<RDSI>> <<RDSI>> Control

52 Módulo 2 UML

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

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

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

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

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

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

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

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

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

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

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

Programación Orientada a Objetos Analista Programador Universitario Plan 2008 Año 2010

Programación Orientada a Objetos Analista Programador Universitario Plan 2008 Año 2010 INTRODUCCION Un concepto fundamental que debemos tener en cuenta a la hora de modelar la realidad por medio de objetos es que los mismos no son entidades aisladas. Los objetos interactúan entre ellos constantemente

Más detalles

Diagramas de clases de UML

Diagramas de clases de UML Qué es UML? UML ( Unified Modeling Language ) es un lenguaje visual para crear modelos de sistemas. Diagramas de clases de UML Franco Guidi Polanco Escuela de Ingeniería Industrial Pontificia Universidad

Más detalles

Trabajo Final De Seminario. Proyecto Alba. Trabajo Final de Seminario Año 2009. Proyecto Alba

Trabajo Final De Seminario. Proyecto Alba. Trabajo Final de Seminario Año 2009. Proyecto Alba Trabajo Final De Seminario 1 UML El UML (Lenguaje Unificado de Modelado) es un lenguaje que permite modelar, construir y documentar los elementos que conforman un sistema software orientado a objetos.

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

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

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

Guía del Curso Analista Programador PHP Javascript

Guía del Curso Analista Programador PHP Javascript Guía del Curso Analista Programador PHP Javascript Modalidad de realización del curso: Número de Horas: Titulación: Online 180 Horas Diploma acreditativo con las horas del curso OBJETIVOS UML usa técnicas

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

Analista Programador PHP Javascript

Analista Programador PHP Javascript TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES Analista Programador PHP Javascript Duración: 420 horas Precio: 0 * Modalidad: Online * hasta 100

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

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

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

CAPÍTULO IV. DISEÑO TÉCNICO CON UML. 4.1. Introducción

CAPÍTULO IV. DISEÑO TÉCNICO CON UML. 4.1. Introducción CAPÍTULO IV. DISEÑO TÉCNICO CON UML 4.1. Introducción Los sistemas o aplicaciones, toman forma cuando una o varias personas tienen la visión de cómo la tecnología puede mejorar las cosas. Los desarrolladores

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

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

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

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

INTRODUCCIÓN AL LENGUAJE DE MODELADO UNIFICADO (UML)

INTRODUCCIÓN AL LENGUAJE DE MODELADO UNIFICADO (UML) INTRODUCCIÓN AL LENGUAJE DE MODELADO UNIFICADO (UML) 1. INTRODUCCIÓN A UML 2. DIAGRAMAS INICIALES 2.1. Casos de Uso 2.1.1. Componentes 2.1.2. Representación gráfica 2.1.3. Tipo de relaciones 2.1.4. Documentación

Más detalles

Curso de UML 2.0: Patrones de Diseño de Software

Curso de UML 2.0: Patrones de Diseño de Software Curso de UML 2.0: Patrones de Diseño de Software Titulación certificada por EUROINNOVA BUSINESS SCHOOL Curso de UML 2.0: Patrones de Diseño de Software Curso de UML 2.0: Patrones de Diseño de Software

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

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

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

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

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

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

Analista Programador Javascript

Analista Programador Javascript Titulación certificada por EUROINNOVA BUSINESS SCHOOL Analista Programador Javascript Analista Programador Javascript Duración: 300 horas Precio: 260 * Modalidad: Online * Materiales didácticos, titulación

Más detalles

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0 Deportes LSI 03 Sistema para Gestión de Artículos Deportivos LSI 03 Versión 3.0 Fecha: 02/01/2003 Historial de Revisiones Fecha Versión Descripción Autor 22/07/2002 0.9 Versión preliminar como propuesta

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

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

INSTITUTO DE EDUCACIÓN SUPERIOR TECNOLÓGICO IBEROTEC SEMESTRE ACADÉMICO: 2014-II SÍLABO UNIDAD DIDÁCTICA : ANÁLISIS Y DISEÑO DE SISTEMAS INFORMÁTICOS

INSTITUTO DE EDUCACIÓN SUPERIOR TECNOLÓGICO IBEROTEC SEMESTRE ACADÉMICO: 2014-II SÍLABO UNIDAD DIDÁCTICA : ANÁLISIS Y DISEÑO DE SISTEMAS INFORMÁTICOS INSTITUTO DE EDUCACIÓN SUPERIOR TECNOLÓGICO IBEROTEC SEMESTRE ACADÉMICO: 201-II 1. DATOS GENERALES SÍLABO UNIDAD DIDÁCTICA : ANÁLISIS Y DISEÑO DE SISTEMAS INFORMÁTICOS MÓDULO : DESARROLLO DE SOFTWARE TIPO

Más detalles

Módulo Profesional 01: Bases de datos (código: 0484).

Módulo Profesional 01: Bases de datos (código: 0484). Módulo Profesional 01: Bases de datos (código: 0484). Actividades de enseñanza-aprendizaje que permiten alcanzar los objetivos del módulo. Interpretar diseños lógicos de bases de datos. Realizar el diseño

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

Curso de UML 2.0: Patrones de Diseño de Software

Curso de UML 2.0: Patrones de Diseño de Software Curso de UML 2.0: Patrones de Diseño de Software TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES Curso de UML 2.0: Patrones de Diseño de Software

Más detalles

Curso de Java POO: Programación orientada a objetos

Curso de Java POO: Programación orientada a objetos Curso de Java POO: Programación orientada a objetos Luis Guerra Velasco Curso INEM 02830. Programación en Java Marzo 2010 Índice 1 Introducción a la POO 2 Herencia y polimorfismo 3 Empaquetado de proyectos

Más detalles

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

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

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

Desarrollo Orientado a Objetos con UML

Desarrollo Orientado a Objetos con UML Desarrollo Orientado a Objetos con UML Facultad de Informática UPM Í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

Más detalles

Diagramas de Clases ~ 1 ~ Ing. Fabián Silva Alvarado

Diagramas de Clases ~ 1 ~ Ing. Fabián Silva Alvarado Diagramas de Clases ~ 1 ~ Ing. Fabián Silva Alvarado DIAGRAMAS DE CLASES RELACIONES ENTRE CLASES Una vez que tengamos todas nuestras clases, será necesario que estas se asocien, con el fin de mostrar la

Más detalles

Instructivo para la elaboración de un Manual Técnico

Instructivo para la elaboración de un Manual Técnico Instructivo para la elaboración de un Manual Técnico Autora: Ing. Alena González Reyes. (agonzalez@ceis.cujae.edu.cu) Ciudad de la Habana, Cuba Marzo, 2010 Índice 1. Introducción... 3 2. Confección...

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

Analista Programador en Visual Basic 2012 (VB.NET 2012)

Analista Programador en Visual Basic 2012 (VB.NET 2012) Analista Programador en Visual Basic 2012 (VB.NET 2012) Titulación certificada por EUROINNOVA BUSINESS SCHOOL Analista Programador en Visual Basic 2012 (VB.NET 2012) Analista Programador en Visual Basic

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

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

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

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

Ingeniería Software software. Análisis de requisitos y especificación de una aplicación

Ingeniería Software software. Análisis de requisitos y especificación de una aplicación Ingeniería Software software 4º Físicas 4º de Físicas Análisis de requisitos y especificación de una aplicación José M. Drake Computadores y Tiempo Real Santander, 1 Ingeniería de Programación (4º Físicas)

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

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

PATRONES DE DISEÑO. FAVA - Formación en Ambientes Virtuales de Aprendizaje. SENA - Servicio Nacional de Aprendizaje

PATRONES DE DISEÑO. FAVA - Formación en Ambientes Virtuales de Aprendizaje. SENA - Servicio Nacional de Aprendizaje PATRONES DE DISEÑO 1. Generalidades 2. Patrones Gof 2.1. Patrones Creacionales 2.1.1.Fábrica Abstracta 2.1.2.Constructor 2.1.3.Método de Factoría 2.1.4.Prototipo 2.1.5.Singleton 2.2. Patrones Estructurales

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

Fundamentos de Ingeniería de Software

Fundamentos de Ingeniería de Software Fundamentos de Ingeniería de Software Marcello Visconti y Hernán Astudillo Departamento de Informática Universidad Técnica Federico Santa María {visconti,hernan} en inf.utfsm.cl Fundamentos de Ingeniería

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

QUÉ ES Y PARA QUÉ SIRVE UML? VERSIONES DEL LENGUAJE UNIFICADO DE MODELADO. TIPOS DE DIAGRAMAS. INGENIERÍA DEL SOFTWARE (DV00205D)

QUÉ ES Y PARA QUÉ SIRVE UML? VERSIONES DEL LENGUAJE UNIFICADO DE MODELADO. TIPOS DE DIAGRAMAS. INGENIERÍA DEL SOFTWARE (DV00205D) APRENDERAPROGRAMAR.COM QUÉ ES Y PARA QUÉ SIRVE UML? VERSIONES DEL LENGUAJE UNIFICADO DE MODELADO. TIPOS DE DIAGRAMAS. INGENIERÍA DEL SOFTWARE (DV00205D) Sección: Divulgación Categoría: Lenguajes y entornos

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

TEMA 5. Contenido. 3.4. Relaciones entre clases... 16

TEMA 5. Contenido. 3.4. Relaciones entre clases... 16 TEMA 5 Contenido 1. INTRODUCCIÓN A LA ORIENTACIÓN A OBJETOS.... 3 El enfoque estructurado.... 3 Enfoque orientado a objetos.... 4 2. CONCEPTOS DE ORIENTACIÓN A OBJETOS.... 5 2.1. Ventajas de la orientació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

UNIVERSIDAD NACIONAL FEDERICO VILLARREAL FACULTAD DE INGENIERÍA ELECTRÓNICA E INFORMÁTICA SÍLABO

UNIVERSIDAD NACIONAL FEDERICO VILLARREAL FACULTAD DE INGENIERÍA ELECTRÓNICA E INFORMÁTICA SÍLABO SÍLABO ASIGNATURA: INGENIERIA DE SISTEMAS DE INFORMACION II CÓDIGO: 8B0023 1. DATOS GENERALES 1.1 DEPARTAMENTO ACADÉMICO : Ingeniería Informática Electrónica 1.2 ESCUELA PROFESIONAL : Ingeniería Informática

Más detalles

Un Método Práctico para comenzar la Especificación de Requerimientos

Un Método Práctico para comenzar la Especificación de Requerimientos DEPARTAMENTO DE INFORMÁTICA. ÁREA SISTEMAS Y GESTIÓN. Casos de Uso Un Método Práctico para comenzar la Especificación de Requerimientos 1. Introducción 1.1. Objetivo de este apunte En uno de los párrafos

Más detalles

GLOSARIO DE TÉRMINOS

GLOSARIO DE TÉRMINOS MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

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

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Rational Unified Process Basado en 6 mejores prácticas de la industria de software: Desarrollo incremental Administración de requisitos Uso de arquitecturas basadas en componentes

Más detalles

Metodología de Diseño para Gestión de Procesos Documentales (MDPD)

Metodología de Diseño para Gestión de Procesos Documentales (MDPD) Metodología de Diseño para Gestión de Procesos Documentales (MDPD) Aquilino A. Juan Fuente Profesor de la Universidad de Oviedo aquilino@lsi.uniovi.es Juan Manuel Cueva Lovelle Catedrático de Escuela de

Más detalles

Técnicas v Prácticas

Técnicas v Prácticas Técnicas v Prácticas ÍNDICE INTRODUCCIÓN... 2 TÉCNICAS DE DESARROLLO... 3 ANÁLISIS COSTE/BENEFICIO... 3 CASOS DE Uso... 7 DIAGRAMA DE CLASES... 12 DIAGRAMA DE COMPONENTES... 18 DIAGRAMA DE DESCOMPOSICIÓN...

Más detalles

UML, ejemplo sencillo sobre Modelado de un Proyecto

UML, ejemplo sencillo sobre Modelado de un Proyecto UML, ejemplo sencillo sobre Modelado de un Proyecto Normal &DOLILFDU 0L3DQRUDPD 626 (VFULEHSDUD1RVRWURV Por Armando Canchala Contenido Introducción Objetivo Requerimientos Casos de Uso Subcasos de Uso

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

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

2.2.- Paradigmas de la POO

2.2.- Paradigmas de la POO 2.2.- Paradigmas de la POO Los principios propios de la orientación a objetos son: 2.2.1.- Abstracción de Datos 2.2.2.- Encapsulamiento 2.2.3.- Ocultamiento 2.2.4.- Herencia 2.2.5.- Polimorfismo Cualquier

Más detalles

Programación Orientada a Objetos INTRODUCCIÓN Y CONCEPTOS

Programación Orientada a Objetos INTRODUCCIÓN Y CONCEPTOS Programación Orientada a Objetos INTRODUCCIÓN Y CONCEPTOS Programación OO Vista Macro: La programación orientada a objetos trata sobre el desarrollo de software utilizando un paradigma que descompone el

Más detalles

Anexo I MÓDULOS PROFESIONALES. 1. Evalúa sistemas informáticos identificando sus componentes y características.

Anexo I MÓDULOS PROFESIONALES. 1. Evalúa sistemas informáticos identificando sus componentes y características. Página I / Anexo I Núm. 135 BOLETÍN OFICIAL DE LA RIOJA Viernes, 21 de octubre de 2011 Módulo Profesional: Sistemas informáticos. Código: 0483 Equivalencia en créditos ECTS: 10 Curso: 1º Duración: 170

Más detalles

Curso de Programación Web en Entorno Servidor

Curso de Programación Web en Entorno Servidor Curso de Programación Web en Entorno Servidor TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES Curso de Programación Web en Entorno Servidor Curso

Más detalles

UNIVERSIDAD POLITÉCNICA SALESIANA FACULTAD DE INGENIERÍAS SEDE QUITO CAMPUS SUR CARRERA DE INGENIERÍA DE SISTEMAS MENCIÓN TELEMÁTICA

UNIVERSIDAD POLITÉCNICA SALESIANA FACULTAD DE INGENIERÍAS SEDE QUITO CAMPUS SUR CARRERA DE INGENIERÍA DE SISTEMAS MENCIÓN TELEMÁTICA UNIVERSIDAD POLITÉCNICA SALESIANA FACULTAD DE INGENIERÍAS SEDE QUITO CAMPUS SUR CARRERA DE INGENIERÍA DE SISTEMAS MENCIÓN TELEMÁTICA ANALISIS, DISEÑO Y CONSTRUCCION DEL SISTEMA PLANIFICADOR DE ACTIVIDADES

Más detalles

Yalù Galicia Hernàndez. Yalú Galicia Hdez. (FCC/BUAP)

Yalù Galicia Hernàndez. Yalú Galicia Hdez. (FCC/BUAP) Yalù Galicia Hernàndez Yalú Galicia Hdez. (FCC/BUAP) 1 Introducción Qué es la Programación Orientada a Objetos? Conceptos básicos Abstracción Jerarquía Encapsulación Objeto Clase Herencia Polimorfismo

Más detalles

Ingeniería de Software: Parte 2

Ingeniería de Software: Parte 2 Ingeniería de Software: Parte 2 Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes.

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

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reutilizable Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Objetivos Para explicar los beneficios del software reutilizable y algunos de sus problemas Para discutir

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

MARCO TEORICO Y CONCEPTUAL

MARCO TEORICO Y CONCEPTUAL 2 CAPITULO I MARCO TEORICO Y CONCEPTUAL 1.1 Antecedentes El Departamento de Recursos Humanos del Hospital Nacional de Niños Benjamín Bloom realiza diversas actividades que se relacionan entre si, desde

Más detalles

Por: Diego Albeiro Alvarez Zuluaga Ingeniero de Sistemas y Telecomunicaciones. Universidad Autónoma de Manizales.

Por: Diego Albeiro Alvarez Zuluaga Ingeniero de Sistemas y Telecomunicaciones. Universidad Autónoma de Manizales. SOFTWARE EDUCATIVO DIRIGIDO A PROLONGAR LOS TIEMPOS DE ATENCIÓN EN NIÑOS DE 7 AÑOS DIAGNOSTICADOS CON TRASTORNO POR DÉFICIT DE ATENCIÓN CON O SIN HIPERACTIVIDAD TDA±H VERSIÓN 2.0 Por: Diego Albeiro Alvarez

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

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

Programación de SMAs

Programación de SMAs Programación de SMAs Juan A. Botía Departamento de Ingeniería de la Información y las Comunicaciones Universidad de Murcia 5 o Curso, Ing. Superior en Informática Juan A. Botía (Departamento de Ingeniería

Más detalles

Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática

Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática Pág: 1 de 6 DEPARTAMENTO DE INGENIERÍA INFORMÁTICA (DII): LS4118: Ingeniería del Software I Documento de DISEÑO Proyecto: XXXXXX Autor/es: YYYYY Pág: 2 de 6 Contenido 1. Introducción 3 2. Diagrama de despliegue

Más detalles

DATOS DE IDENTIFICACION DEL CURSO DEPARTAMENTO:

DATOS DE IDENTIFICACION DEL CURSO DEPARTAMENTO: DATOS DE IDENTIFICACION DEL CURSO DEPARTAMENTO: Departamento de Ciencias Computacionales ACADEMIA A LA QUE PERTENECE: Ingeniería de Software NOMBRE DE LA MATERIA: Ingeniería de Software II CLAVE: CC305

Más detalles

Ingeniería del Software

Ingeniería del Software Tema 2: Modelo objeto Una descripción de UML Dr. Francisco José García Peñalvo (fgarcia@usal.es) Miguel Ángel Conde González (mconde@usal.es) Sergio Bravo Martín (ser@usal.es) 3º I.T.I.S. Fecha de última

Más detalles

CONCEPTOS FUNDAMENTALES DE LA ORIENTACION A OBJETOS

CONCEPTOS FUNDAMENTALES DE LA ORIENTACION A OBJETOS CAPITULO 3 CONCEPTOS FUNDAMENTALES DE LA ORIENTACION A OBJETOS 3.1. QUE ES LA PROGRAMACIÓN ORIENTADA A OBJETOS? La POO no es un lenguaje de programación. La POO es una nueva manera de "atacar" los problemas

Más detalles