Notación UML para modelado Orientado a Objetos

Save this PDF as:
 WORD  PNG  TXT  JPG

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

Download "Notación UML para modelado Orientado a Objetos"

Transcripción

1 1 Notación UML para modelado Orientado a Objetos

2 2 Notación UML para modelado Orientado a Objetos Índice 1.1. Qué es UML? Por qué interesa UML en la asignatura de Programación Orientada a Objetos? Qué se va a modelar? Diagramas Diagramas de Clases Diagramas de Objetos Diagramas de Interacción Diagramas de secuencia Diagramas de colaboración Clases Clases Abstractas Interfaces Objetos Relaciones Detalles Navegabilidad Multiplicidad Rol Composición Uso Asociación Herencia Recapitulación Consideraciones Bibliografía. 17

3 Qué es UML? El Lenguaje Unificado de Modelado (UML, Unified Modeling Language) es un lenguaje estándar, basado en una notación gráfica, que se utiliza para modelar software. Es un lenguaje de propósito general que pretende ser un estándar mundial y se utiliza para visualizar, especificar, construir y documentar las diferentes piezas de un sistema. Qué es un modelo? Una simplificación de la realidad. Por qué se modela? Se construyen modelos para poder entender mejor el sistema a desarrollar, o bien, un sistema desarrollado Por qué interesa UML en la asignatura de Programación Orientada a Objetos? En la asignatura de Programación Orientada a Objetos se aprende un nuevo paradigma de programación: el paradigma orientado a objetos. A su vez, se utiliza el lenguaje Java para implementar el código de los programas orientados a objetos. Para modelar los programas de forma gráfica, viendo las relaciones entre las clases y cómo colaboran unos objetos con otros, se prefiere utilizar una notación estándar. De esta manera, el alumno va conociendo parte de la notación, UML en este caso, lo cual le será útil por varias razones: Le permite ir familiarizándose con un lenguaje de modelado estándar que verá en otras asignaturas de la titulación. Le permite entender modelos con esta notación. Por todo ello, se verá cómo implementar en código Java un modelo diseñado con UML. De esta manera, se podrán hacer diagramas modelando los programas orientados a objetos que se implementen con el lenguaje Java Qué se va a modelar? Se presentará una selección de las características más representativas de UML. De éstas no se detallará todo de forma completa, sino sólo aquello que nos interese para representar nuestros diseños orientados a objetos implementados con el lenguaje Java.

4 4 Notación UML para modelado Orientado a Objetos Además, conviene dejar claro que: UML es un lenguaje de modelado Java es un lenguaje de implementación Por lo tanto, no existe una representación única para código Java, ni tampoco unas reglas exactas de dado cierto código, entonces cierta representación, que se puedan seguir siempre. De hecho, dos modelados diferentes pueden tener el mismo código asociado, por lo que no hay viaje de vuelta. Es decir, dado un código no es posible determinar las relaciones entre las diferentes clases y, por lo tanto, cual es la representación UML. Se trata de un modelado a nivel conceptual. El estándar UML no pide que se indique todo en los diagramas, sino que lo que se refleje en ellos sea cierto. En nuestro caso, dado un programa orientado a objetos nos interesa tanto su visión estática como su visión dinámica. La visión estática se puede ver como un conjunto de clases que permiten alcanzar altas cotas de abstracción, encapsulación, modularidad y jerarquía. Por otra parte, la visión dinámica de un programa se puede ver como un conjunto de objetos, los cuales colaboran entre sí mediante el desencadenamiento de instanciaciones y de paso de mensajes. Por ello, se van a modelar tanto los aspectos estáticos como los aspectos dinámicos de un programa orientado a objetos. Los aspectos estáticos se modelan mediante diagramas de clases y diagramas de objetos. Los primeros se componen de un conjunto de clases y las relaciones entre ellas, mientras que en los segundos las relaciones se dan entre un conjunto de objetos. Los aspectos dinámicos se modelan mediante diagramas de interacción. Éstos, presentan la forma en la que interactúan los diferentes objetos del diagrama Diagramas Diagramas de Clases Los diagramas de clases proporcionan una perspectiva estática del código. Se componen de: Clases o Gráficamente se representan mediante un rectángulo con el nombre de la clase. Relaciones o De forma gráfica se trata de una línea que une las clases que relaciona. Un ejemplo de diagrama de clases se presenta en la figura 1.

5 5 Ter Turno Tablero Ficha Coordenada Figura 1. Diagrama de clases Diagramas de Objetos Los diagramas de objetos proporcionan una perspectiva estática de una ejecución del código. Presentan instantáneas de instancias de los elementos que aparecen en los diagramas de clases. En definitiva, muestran un conjunto de objetos y sus relaciones en un momento concreto ( fotografía de un momento determinado). Básicamente se componen de: Objetos o De forma gráfica se representa mediante un rectángulo con el nombre del objeto. Relaciones Un ejemplo de diagrama de objetos se presenta en la figura 2.

6 6 Notación UML para modelado Orientado a Objetos :Ter :Turno :Tablero :Coordenada : : :Ficha :Coordenada :Ficha :Ficha Figura 2. Diagrama de objetos La diferencia clara entre un diagrama de clases y un diagrama de objetos es que el primero representa los aspectos estáticos del sistema, y el segundo los aspectos estáticos de una interacción concreta entre los objetos Diagramas de Interacción En los diagramas de interacción se puede ver el patrón de comportamiento de un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto para lograr un propósito. Son dos los tipos de diagramas de interacción: secuencia y colaboración. Ambos están basados en la misma información, aunque cada uno enfatiza un aspecto diferente: el diagrama de secuencia destaca la ordenación temporal de los mensajes y el diagrama de colaboración destaca la organización estructural (qué objetos colaboran con otros) de los objetos que intercambian mensajes Diagramas de secuencia Estos diagramas presentan, ordenados temporalmente, los objetos que participan en una interacción y los mensajes que se intercambian. En el diagrama, en cada eje vertical se coloca un objeto. Los mensajes se representan mediante flechas horizontales de un objeto a otro, donde el retorno se representa mediante una línea punteada del objeto pasivo al objeto agente del mensaje. El tiempo fluye de arriba hacia abajo. Un ejemplo de diagrama de secuencia de presenta en la figura 3.

7 7 ter:ter turno:turno t:tablero j: jugar() mostrar() poner(t) cambiar() mostrar() Figura 3. Diagrama de secuencia Para especificar quién y cuándo se crean los objetos, se utiliza el estereotipo 1 <<create>>. Como ejemplo se presenta el diagrama de la figura 4. j: t:tablero poner(t) <<create>> c:coordenada recoger() poner(c,f) Figura 4. Diagrama de secuencia con estereotipos 1 Estereotipo: mecanismo de extensibilidad de UML para representar una distinción de uso. Es aplicable a cualquier elemento de modelado.

8 8 Notación UML para modelado Orientado a Objetos Diagramas de colaboración Un diagrama de colaboración también muestra la interacción entre los objetos, pero basándose en las relaciones entre ellos. En la figura 5 se puede ver un ejemplo de diagrama de colaboración. 1: jugar() ter:ter 5: mostrar() 2: mostrar() t:tablero 4: cambiar() j: 3: poner(t) turno:turno Figura 5. Diagrama de colaboración El diagrama de secuencia y el diagrama de colaboración son equivalentes, ambos muestran una interacción entre los objetos. Simplemente uno de ellos destaca la ordenación temporal y el otro la estructura de la interacción Clases Las clases de Java se representarán tal como aparece en la figura 6. Se trata de un rectángulo dividido en tres partes: la parte superior indica el nombre de la clase; la parte central contiene los atributos y, por último, la parte inferior presentará las operaciones de la clase. NombreClase Atributos Operaciones Figura 6. Representación de una clase con UML Los niveles de visibilidad de los elementos se representan como sigue: Privado: - Protegido: # Público: + En la figura 7 se presenta un ejemplo de clase Java junto con su representación UML.

9 9 Ficha class Ficha { -color:char +mostrar() +igual(ficha):boolean private char color; public void mostrar() { public boolean igual(ficha ficha) { Figura 7. Ejemplo de representación de una clase con UML Clases Abstractas La representación para las clases abstractas es igual que para las clases normales, salvo que el nombre de la clase se escribe en cursiva, como se puede apreciar en la figura 8. ClaseA abstract class ClaseA { Figura 8. Representación de una clase abstracta con UML Interfaces Una interfaz se representa exactamente igual que una clase normal, salvo que se añade un estereotipo ( <<interface>> en este caso) en la parte superior del rectángulo, indicando, precisamente, que se trata de una interfaz y no de una clase normal. En la figura 9 se presenta un ejemplo. <<interface>> InterfazA interface InterfazA { Figura 9. Representación de un interfaz con UML

10 10 Notación UML para modelado Orientado a Objetos 1.6. Objetos Para representar una instancia concreta de una clase con la notación UML también se utiliza un rectángulo con tres partes. En la primera se especifica el nombre del objeto separado por dos puntos del nombre de la clase, todo ello subrayado. En la segunda parte aparecerán los atributos del objeto con sus valores. Aquellos atributos compartidos por todas las instancias de una clase no se añaden aquí. Por último, en la parte inferior del rectángulo van las operaciones que puede realizar el objeto por pertenecer a una clase determinada, aunque éstas se pueden omitir. También es posible, entre otras cosas, omitir la parte central del rectángulo e, incluso, poner sólo la clase del objeto sin hacer referencia a su nombre. Ejemplos de esta notación se pueden ver en la figura 10. f:ficha f:ficha color=` :Ficha Figura 10. Notación UML para representar objetos En nuestro caso utilizaremos la notación en la que aparece simplemente el nombre de la clase a la que pertenece el objeto (ver figura 11). La razón es porque realmente qué nombre tienen los objetos?, es decir, qué ocurre si se tienen muchas referencias al mismo objeto? ( cuál de todos los nombres de esas referencias se refleja en el diagrama?). :Ficha Figura 11. Notación UML para objetos con nombre de clase únicamente 1.7. Relaciones Cuando se realizan abstracciones son pocas las clases que actúan solas; lo normal es que existan diferentes relaciones entre las clases. Entre clases pueden existir cuatro tipos de relación: composición, asociación, uso y herencia. Las tres primeras se dan cuando objetos de las clases colaboran entre sí. Sin embargo, el hecho de que exista una relación de herencia entre dos clases no implica que los objetos de dichas clases colaboren, puede que nunca lo hagan Detalles Se tendrán en cuenta una serie de detalles para todas las relaciones. Estos detalles deberán acompañar a la relación en los diagramas.

11 Navegabilidad Se contemplará la navegabilidad en las relaciones, es decir, el sentido de las mismas. Se representará mediante una flecha, la cual indica que es posible navegar desde el objeto de la clase origen al objeto de la clase destino. Por tanto, el objeto de la clase origen conoce a los objetos de la clase destino, de manera que podrá invocar operaciones de éstos. En la figura 12 se presenta un ejemplo de navegabilidad. Ficha class { private Ficha ficha; Figura 12. Navegabilidad entre clases Si se observa la figura anterior, atendiendo solo a la navegabilidad, se puede ver que un objeto de la clase conoce a un objeto de la clase Ficha, por consiguiente, le puede lanzar mensajes, y no al revés Multiplicidad La multiplicidad consiste en especificar el rango de cardinalidades que puede asumir un conjunto, de forma que se indica cuántos objetos de una clase se relacionan con objetos de la otra clase que forma parte de la relación. Las restricciones de multiplicidad se deberán indicar en el diagrama. En UML es posible especificar la multiplicidad de una clase mediante una expresión en la esquina superior derecha de la misma e, incluso, también se puede especificar la multiplicidad para los atributos. En nuestro caso, simplemente reflejaremos la multiplicidad en los diagramas de clases a nivel de las relaciones entre clases. Por lo tanto, se especificará el número de instancias de una clase que se relaciona con instancias de otra clase, y se indicará al lado de la clase cuyo número de instancias se intenta precisar. En la figura 13 se puede ver un ejemplo. Ficha class { private Ficha ficha; Figura 13. Multiplicidad de la relación entre clases Las multiplicidades con valor 1 no se suelen representar, lo cual queda patente mediante el diagrama presentado en la figura anterior. En este caso, un objeto de la clase Ficha forma parte de un único objeto de la clase y, a su vez, un objeto de la clase tiene un único objeto de la clase Ficha. Para representar una multiplicidad de varios elementos, donde no se sabe el número exacto que tienen, se suele indicar mediante el rango posible. Por ejemplo: 0..

12 12 Notación UML para modelado Orientado a Objetos *, 1..*, etc. En nuestro caso, simplemente indicaremos la parte máxima del rango y, además, utilizaremos una restricción 2 para indicar el tipo de secuencia de elementos que es. Por ejemplo: {array (si es una tabla normal), {ArrayList (si se trata de un objeto de la clase ArrayList de Java), {List (si se trata de un objeto de la clase List de Java), etc. Un ejemplo se presenta en la figura 14. Ter {array 2 class Ter { private final [ ] JUGADORES = new [2]; Figura 14. Uso de restricciones en la multiplicidad de la relación entre clases En el ejemplo presentado en la figura 14 se conoce el número exacto de la multiplicidad. En caso de ser mayor que 1 y no conocerse con exactitud se indicará con * Rol Por último, con respecto al nombre de la relación, éste no será especificado. Lo que si se reflejará en los diagramas será el rol que juega en la relación la clase destino de la navegación. El rol es el comportamiento de una entidad que participa en un contexto particular. Es decir, se indica el rol que juega una clase dentro de la relación con otra clase. De forma general se presenta un ejemplo en la figura 15. El nombre del rol que desempeña la clase se especifica al lado de ésta. Empresa Empleado trabajador Figura 15. Roles de las clases Además, en nuestro caso, el rol de la clase será el nombre del atributo. Un ejemplo se presenta en el diagrama de la figura 16. ficha Ficha class { private Ficha ficha; Figura 16. Rol de la clase Ficha en la relación con 2 Restricción: restricción de la semántica de un elemento de UML, que permite añadir nuevas reglas o modificar las existentes.

13 Composición La relación de composición es la relación entre el todo y la parte, siendo responsabilidad del todo lo que le ocurra a cada una de las partes. En UML, para referirse a este tipo de relación, se hace distinción entre Composición y Agregación. Nosotros simplemente vamos a referirnos a composición, representando la relación como una línea acabada en un rombo en el extremo de la clase que representa el todo (ver figura 17). tablero Tablero Ter class Ter { 2 JUGADORES private Tablero tablero; private final [ ] JUGADORES; Figura 17. Relación de composición entre clases Uso La relación de uso (en UML se denomina de dependencia) es una relación momentánea que se establece entre un cliente y un servidor. La responsabilidad de manejar un objeto servidor no tiene porqué depender únicamente de la clase cliente. En UML se representa mediante una línea punteada que une ambas clases. En la figura 18 se presenta un ejemplo de relación de uso. Coordenada class { public void mover(tablero tablero) { Coordenada c = new Coordenada(); c.recoger(); Figura 18. Relación de uso entre clases En el caso de la relación de uso no hay posible rol a establecer (siguiendo la pauta de que el rol sea el nombre del atributo) Asociación La relación de asociación es una relación que perdura entre un cliente y un servidor, donde la responsabilidad de manejar el objeto de la clase servidor no tiene porqué depender, únicamente, de la clase cliente. Esta relación se representa en UML mediante una línea que une ambas clases, como se puede apreciar en la figura 19.

14 14 Notación UML para modelado Orientado a Objetos ficha Ficha class { private Ficha ficha; Figura 19. Relación de asociación entre clases Herencia La relación de herencia (en UML denominada Generalización) es aquella que se establece entre dos clases, transmitiendo tanto atributos como métodos de la clase padre a la clase hija. La clase hija será una especialización de la clase padre. En este caso la representación UML se realiza mediante un triángulo en el extremo de la relación donde se encuentra la clase más general, la clase padre (ver figura 20). ClasePadre ClaseHija class ClaseHija extends ClasePadre { Figura 20. Relación de herencia entre clases La representación es la misma si la relación de herencia se da entre interfaces (ver figura 21), o si una clase hereda por implementación de una interfaz (ver figura 22). <<interface>> InterfazPadre <<interface>> InterfazHijo interface InterfazHijo extends InterfazPadre { Figura 21. Relación de herencia entre interfaces

15 15 <<interface>> InterfazPadre ClaseHija class ClaseHija implements InterfazPadre { Figura 22. Relación de herencia por implementación 1.8. Recapitulación Una vez estudiados todos los detalles de clases, objetos y relaciones, en este apartado se presentan de nuevo los diagramas de clases y objetos mostrados en el apartado 1.4. Dichos diagramas se han completado indicando los tipos de relaciones entre las clases, la navegabilidad, la multiplicidad, los roles, etc. El diagrama de clases completo se presenta en la figura 23. Ter turno Turno JUGADORES 2 {array tablero Tablero ficha FICHAS Ficha {array * Coordenada Figura 23. Diagrama de clases completo El diagrama de objetos que se tenía se ha completado añadiendo la navegabilidad, quedando como se muestra en la figura 24.

16 16 Notación UML para modelado Orientado a Objetos :Ter :Turno :Tablero :Coordenada : : :Ficha :Coordenada :Ficha :Ficha Figura 24. Diagrama de objetos completo 1.9. Consideraciones Observando la notación gráfica de UML para las clases, se puede apreciar que se indican los diferentes atributos de una clase. Estos atributos pueden ser objetos de otras clases, lo que va a marcar seguro algún tipo de relación entre ellas. Por lo tanto, es necesario tomar una decisión con respecto al lugar en el que se ponen dichos atributos, de forma que en el diagrama de clases no sea redundante. Un ejemplo de esta situación se muestra en la figura 25. Persona fechanacimiento: Fecha Libro publicacion: Fecha (a) Persona Fecha Libro fechanacimiento publicacion (b) Figura 25. Equivalencia parcial entre notaciones

17 17 Como se puede apreciar, en la figura 25(a) el atributo que hace referencia a la fecha de nacimiento de una persona va incluido en la parte central de la notación gráfica de la clase Persona. Sin embargo, en la figura 25(b) la fecha de nacimiento de la persona se manifiesta a través de una relación entre clases. Para intentar unificar la forma de representar nuestros programas orientados a objetos, en principio se va a optar por la segunda opción (figura 25(b)), y sólo en aquel caso en el que el diagrama esté muy cargado, se optará por representar algunos atributos mediante la primera opción (figura 25(a)) Bibliografía G. Booch, I. Jacobson, J. Rumbaugh; El Lenguaje Unificado de Modelado. Manual de Referencia. Addison Wesley.

Í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

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

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

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

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

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

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

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

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

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.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

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

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

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

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

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

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

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

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

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

Relaciones entre clases: Diagramas de clases UML

Relaciones entre clases: Diagramas de clases UML Relaciones entre clases: Diagramas de clases UML Las relaciones existentes entre las distintas clases nos indican cómo se comunican los objetos de esas clases entre sí: Los mensajes navegan por las relaciones

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

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

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

Programación Orientada a Objetos en Java

Programación Orientada a Objetos en Java Programación Orientada a Objetos en Java Curso 2006-2007 Tema 4 Herencia y Polimorfismo Gonzalo Méndez Pozo Dpto. de Ingeniería de Software e Inteligencia Artificial Universidad Complutense de Madrid Herencia

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

Java Inicial (20 horas)

Java Inicial (20 horas) Java Inicial (20 horas) 1 Temario 1. Programación Orientada a Objetos 2. Introducción y Sintaxis Java 3. Sentencias Control Flujo 4. POO en Java 5. Relaciones entre Objetos 6. Polimorfismo, abstracción

Más detalles

PROPUESTA DE UN SISTEMA DE EVALUACIÓN EN LA WEB PARA LA EDUCACIÓN. Maria Soledad Zangla, Marcela C. Chiarani y Ma.

PROPUESTA DE UN SISTEMA DE EVALUACIÓN EN LA WEB PARA LA EDUCACIÓN. Maria Soledad Zangla, Marcela C. Chiarani y Ma. PROPUESTA DE UN SISTEMA DE EVALUACIÓN EN LA WEB PARA LA EDUCACIÓN Maria Soledad Zangla, Marcela C. Chiarani y Ma. Margarita Lucero Grupo De Investigación Ambientes Colaborativos Inteligentes Departamento

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

Introducción a la programación orientada a objetos

Introducción a la programación orientada a objetos Introducción a la programación orientada a objetos 1. Introducción a la programación orientada a objetos 2. Las clases 3. El tipo Struct 4. Diferencias entre Class y Struct 5. Pilares de la Programació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

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

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

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

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

Space Invaders Práctica de la Asignatura de Programación Orientada a Objetos Escenario para el Curso 2011/2012 Febrero de 2012 Versión 1.

Space Invaders Práctica de la Asignatura de Programación Orientada a Objetos Escenario para el Curso 2011/2012 Febrero de 2012 Versión 1. Space Invaders Práctica de la Asignatura de Programación Orientada a Objetos Escenario para el Curso 2011/2012 Febrero de 2012 Versión 1.1 Departamento de Lenguajes y Sistemas Informáticos Escuela Técnica

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

Modelado arquitectónico con UML

Modelado arquitectónico con UML Modelado arquitectónico con UML Qué es la arquitectura de software El modelo de 4+1 vistas arquitectónicas Cohesión y acoplamiento Cómo lograr una descomposición modular eficaz Criterios para la selección

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

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

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

FUNDAMENTOS DE LA TEORÍA DE SISTEMA

FUNDAMENTOS DE LA TEORÍA DE SISTEMA FUNDAMENTOS DE LA TEORÍA DE SISTEMA AL TERMINAR LA CLASE UD PODRÁ RESPONDER Qué es un sistema? Cómo pueden ser definidos los sistemas? Cuáles son los parámetros de un sistema? Cuáles son las característica

Más detalles

Figura 1: versión original del juego Super Pang!

Figura 1: versión original del juego Super Pang! MOO PANG!: DOCUMENTO DE ANÁLISIS INTRODUCCIÓN Una pequeña empresa de videojuegos nos pide una versión sencilla del conocido videojuego Pang! (ver figura). En este videojuego, unas burbujas van cayendo

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

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

Programación en Java. Programación en OO

Programación en Java. Programación en OO Programación en OO Lección 4:Programación en OO 1. Herencia 2. Modificadores de Acceso 3. Interfaces Herencia Es la acción en la que una clase obtiene los métodos y propiedades definidos en otra clase,

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

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

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

Diseño orientado a los objetos

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

Más detalles

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

Introducción a la P.O.O. Patrick Hernández Cuamatzi

Introducción a la P.O.O. Patrick Hernández Cuamatzi Introducción a la P.O.O. Patrick Hernández Cuamatzi Introducción } Debemos diferenciar entre Programación Orientada a Objetos (P.O.O.) y Lenguaje Orientado a Objetos (L.O.O.). } La P.O.O. es una filosofía,

Más detalles

Conceptos. ELO329: Diseño y Programación Orientados a Objetos. ELO 329: Diseño y Programación Orientados a Objetos

Conceptos. ELO329: Diseño y Programación Orientados a Objetos. ELO 329: Diseño y Programación Orientados a Objetos Conceptos ELO329: Diseño y Programación Orientados a Objetos 1 Paradigmas de Programación Historia: Los computadores parten cableados por hardware, Luego se introduce la programación en binario, Se desarrolla

Más detalles

Maestría en Bioinformática. Bases de Datos y Sistemas de Información. Diseño Conceptual. Ing. Alfonso Vicente, PMP alfonso.vicente@logos.com.

Maestría en Bioinformática. Bases de Datos y Sistemas de Información. Diseño Conceptual. Ing. Alfonso Vicente, PMP alfonso.vicente@logos.com. Maestría en Bioinformática Bases de Datos y Sistemas de Información Diseño Conceptual Ing. Alfonso Vicente, PMP alfonso.vicente@logos.com.uy Agenda Conceptos Elementos del MER Herramientas Diseño conceptual

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

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

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

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

1. Qué tipos de relación hay entre las siguientes clases?

1. Qué tipos de relación hay entre las siguientes clases? Ejercicios Tema 8: Herencia 1. Qué tipos de relación hay entre las siguientes clases? Personal de la Universidad PAS Profesor 1 n Estudiante a) herencia y asociación b) herencia y dependencia c) dependencia

Más detalles

INTRODUCCIÓN al Lenguaje de Modelado Unificado

INTRODUCCIÓN al Lenguaje de Modelado Unificado 1 de 22 INTRODUCCIÓN al Lenguaje de Modelado Unificado INTRODUCCIÓN AL LENGUAJE DE MODELADO UNIFICADO...1 1. QUÉ ES EL UML?...2 2. CLASES Y OBJETOS...3 2.1. Clases, atributos y operaciones...3 2.2. Implementación

Más detalles

Repetir el proceso para cada abstracción identificada hasta que el diseño este expresado en términos sencillos

Repetir el proceso para cada abstracción identificada hasta que el diseño este expresado en términos sencillos I. INTRODUCCIÓN El reciente aumento de aplicaciones en donde se utiliza la computadora ha sido posible debido a un hardware de bajo costo, por lo cual la demanda de software ha crecido de forma exponencial.

Más detalles

Ingeniería del Software I

Ingeniería del Software I - 1 - Ingeniería del Software I Introducción al Modelo Conceptual 2do. Cuatrimestre 2005 INTRODUCCIÓN... 2 CLASES CONCEPTUALES... 3 ESTRATEGIAS PARA IDENTIFICAR CLASES CONCEPTUALES... 3 Utilizar lista

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

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

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

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

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

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

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

Clases abstractas e interfaces

Clases abstractas e interfaces Clases abstractas e interfaces Clases abstractas Una clase abstracta es una clase que no se puede instanciar se usa únicamente para definir subclases Cuándo es una clase abstracta? En cuanto uno de sus

Más detalles

6.8 La Arquitectura del Sistema. [Proceso]

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

Más detalles

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

Introducción a la Programación Orientada a Objetos

Introducción a la Programación Orientada a Objetos Introducción a la Programación Orientada a Objetos El paradigma imperativo. En un programa se tienen una serie de variables con las cuales operamos y modificamos mediante sentencias y funciones para producir

Más detalles

JavaScript como Orientación a Objetos

JavaScript como Orientación a Objetos Gustavo Lacoste (gustavo@lacosox.org) October 2012 Resumen El objetivo de las siguientes notas es generar una estructura en JavaScript que nos permita reutilizar de manera limpia las funciones creadas

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

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

: COMPUTACIÓN E INFORMATICA : Ingeniería de Software Ingeniería de Redes y Comunicaciones : Análisis y Diseño de Sistemas : T-INF107

: COMPUTACIÓN E INFORMATICA : Ingeniería de Software Ingeniería de Redes y Comunicaciones : Análisis y Diseño de Sistemas : T-INF107 I. DATOS INFORMATIVOS Carrera Especialidad Curso Código Ciclo : Tercero Requisitos Duración Horas Semana : 06 horas Versión : v.0110 II. SUMILLA: : COMPUTACIÓN E INFORMATICA : Ingeniería de Software Ingeniería

Más detalles

Multitarea en Java. Rafa Caballero - UCM

Multitarea en Java. Rafa Caballero - UCM Multitarea en Java Rafa Caballero - UCM Programa Monoproceso (monotarea) En cada momento hay una única instrucción ejecutándose Se dice que el programa es monotarea, o monoproceso o monohebra (o single

Más detalles

UML Diagramas de Clases

UML Diagramas de Clases UML (UML ilustrado) Universidad de Los Andes Demián Gutierrez Marzo 2011 1 ( Qué Muestran?) La estructura estática del sistema modelado (piense en el plano estructural de un ingeniero civil) Las relaciones

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

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

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

Más detalles

En un proyecto de desarrollo de software la metodología define Quién debe hacer Qué, Cuando y Como hacerlo. 6

En un proyecto de desarrollo de software la metodología define Quién debe hacer Qué, Cuando y Como hacerlo. 6 2. MÉTODO, METODOLOGÍA Y MÉTRICA 2.1 MÉTODO Un método de ingeniería del software es un enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la producción de software de alta

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

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

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

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

1. Generación automática de documentación (javadoc)

1. Generación automática de documentación (javadoc) Índice 1. Generación automática de documentación (javadoc)... 1 1.1 Introducción... 1 1.2 La herramienta Javadoc... 1 1.3 Comentando el código Java... 1 2 Guía de estilo de Java... 5 2.1 Clases... 6 2.2

Más detalles

Tema 2: Modelo Entidad-Asociación (E-A)

Tema 2: Modelo Entidad-Asociación (E-A) Tema 2: Modelo Entidad-Asociación (E-A) Conjuntos entidad Conjuntos asociación Cuestiones de diseño Restricciones de asociaciones Claves Diagrama E-A Características del modelo E-A ampliado Diseño de un

Más detalles

2.4 Modelado conceptual

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

Más detalles

CENTRO DE CIENCIAS BÁSICAS DEPARTAMENTO DE SISTEMAS DE INFORMACIÓN PROGRAMA DE MATERIA HORAS T/P: 2/2

CENTRO DE CIENCIAS BÁSICAS DEPARTAMENTO DE SISTEMAS DE INFORMACIÓN PROGRAMA DE MATERIA HORAS T/P: 2/2 CENTRO DE CIENCIAS BÁSICAS DEPARTAMENTO DE SISTEMAS DE INFORMACIÓN PROGRAMA DE MATERIA MATERIA: ANALISIS Y DISEÑO ORIENTADO A OBJETOS HORAS T/P: 2/2 CARRERA: ING. EN SISTEMAS COMPUTACIONALES CRÉDITOS:

Más detalles

BANCO DE PREGUNTAS PARA EVALUACIÓN DE CONOCIMIENTOS DEL CONCURSO DE MÉRITOS Y OPOSICIÓN EXPERTO EN DESARROLLO DE SISTEMAS 1

BANCO DE PREGUNTAS PARA EVALUACIÓN DE CONOCIMIENTOS DEL CONCURSO DE MÉRITOS Y OPOSICIÓN EXPERTO EN DESARROLLO DE SISTEMAS 1 BANCO DE PREGUNTAS PARA EVALUACIÓN DE CONOCIMIENTOS DEL CONCURSO DE MÉRITOS Y OPOSICIÓN EXPERTO EN DESARROLLO DE SISTEMAS 1 1. Cuáles de los siguientes enunciados son declaraciones válidas? 2. Cuál de

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

Lenguajes de Programación Curso 04-05. Práctica 4. Herencia. Utilización de interfaces y clases abstractas. 1. Interfaces 1. 2. Clases abstractas 2

Lenguajes de Programación Curso 04-05. Práctica 4. Herencia. Utilización de interfaces y clases abstractas. 1. Interfaces 1. 2. Clases abstractas 2 Objetivos Herencia. Utilización de interfaces y clases abstractas. Índice 1. Interfaces 1 2. Clases abstractas 2 3. Collections Framework 3 3.1. Collection........................................... 3

Más detalles

Objetivo Las personas que realicen el curso aprenderán a:

Objetivo Las personas que realicen el curso aprenderán a: Objetivo Las personas que realicen el curso aprenderán a: Describir el proceso de desarrollo de software orientado a objetos, lo que incluye las metodologías y los flujos de trabajo de la programación

Más detalles

Práctica 2 Gráficos Vectoriales con SVG (versión 29.09.14)

Práctica 2 Gráficos Vectoriales con SVG (versión 29.09.14) Práctica 2 Gráficos Vectoriales con SVG (versión 29.09.14) Programación 3 Curso 2011-2012 Departamento de Lenguajes y Sistemas Informáticos Universidad de Alicante 1. Introducción En esta segunda práctica

Más detalles

POLIMORFISMO "una interfaz, múltiples métodos".

POLIMORFISMO una interfaz, múltiples métodos. "una interfaz, múltiples métodos". 20/02/2007 Polimorfismo 2 Indice Definición y caracteristicas Objetivos. SOBRRESCRITURA-SOBRECARGA SOBRECARGA Clases y métodos abstractos INTERFACES (herencia múltiple)

Más detalles

Práctica Java POJO de Integración de Sistemas Tienda de Comercio Electrónico

Práctica Java POJO de Integración de Sistemas Tienda de Comercio Electrónico Práctica Java POJO de Integración de Sistemas Tienda de Comercio Electrónico Curso académico 2008-2009 1 Introducción La práctica de Integración de Sistemas consistirá en el diseño e implementación de

Más detalles

Tecnología de Programación

Tecnología de Programación Tecnología de Programación Clase 6 Diego C. Martínez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Lenguaje de modelado unificado UML (Unified Modeling Language)

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

Principios Básicos de Orientación a Objetos. Orientación a Objetos

Principios Básicos de Orientación a Objetos. Orientación a Objetos Principios Básicos de Orientación a Objetos Orientación a Objetos Abstracción Encapsulación Modularidad Jerarquia Qué es Abstracción? Es la capacidad de conceptualizar entidades genéricas de información

Más detalles

Desarrollo de Software

Desarrollo de Software Especialización en Telemática Desarrollo de Software Arquitecturas de Sistemas Telemáticos Dr. Ing. Álvaro Rendón Gallón Cali, mayo de 2012 Temario 2 Tarea 1: Ordenar datos Tarea 2: Un juego en red Consideraciones

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