TALLER CONCEPTUALIZACION

PROGRAMACION ORIENTADA A OBJETOS

TECNOLOGIA EN ANALISIS Y DESARROLLO DE SISTEMAS DE INFORMACION

FICHAS: 581708 – 600182

Instructor: Iván Daniel Vela Montenegro

Nombre: Víctor Manuel Nemocón Beltrán Ficha: 600182 Fecha: 27/03/14

Investigar los siguientes conceptos relacionados con la Programación Orientada a Objetos y el

Lenguaje Unificado de Modelado. Para cada ítem agregar un ejemplo que represente el

concepto. (No aplica para todos los conceptos)

1. Clase:

Cada clase tiene asociado un código:

Programar orientado a objetos consiste en escribir código de clases de objetos

Los métodos que pueden ejecutar los objetos de la clase y cómo lo hacen

Cada clase tiene asociado un código (definición de la clase), que determina

Los atributos que tienen los objetos de la clase

2. Objeto:

Los objetos pueden ser reales o imaginarios

Los objetos pueden ser simples o complejos

Los objetos son/representan cosas

3. Propiedades:

Las propiedades de un objeto pueden tomar uno o varios valores. Estos valores

pueden ser de cualquier tipo de dato (String o cadena de caracteres).

Las propiedades de un objeto toman un valor que puede ser permanente o puede

cambiar. El valor concreto de una propiedad de un objeto se llama estado del objeto.

Podemos modificar la propiedad de un objeto accediendo a su estado.

4. Métodos:

1. Acciones que puede realizar un objeto (automóvil):

o Arrancar motor

o Parar motor

o Acelerar

o Frenar

o Girar a la derecha (grados)

o Girar a la izquierda (grados)

2. Los métodos pueden devolver un valor al acabar su Ejecución:

o Valor de retorno

5. Estado:

Un estado es la descripción completa del objeto.

6. UML:

(Unified Modeling Language) lenguaje unificado de modelado, Se utiliza para definir

un sistema, para detallar los artefactos en el sistema y para documentar y construir.

Es el lenguaje en el que está descrito el modelo.

7. ArgoUML:

Es una versión más avanzada de UML solo que está escrita en java únicamente.

8. Eventos:

Paradigma de programación en el que la estructura y ejecución del programa

dependen de los sucesos (eventos) que ocurran en el sistema o que ellos mismos

provoquen.

El programador debe definir los eventos a los cuales el programa reaccionará y las

acciones que seguirá al presentarse cada uno, esto se conoce como manejador de

eventos.

Existen múltiples eventos y dependen del sistema operativo y del lenguaje de

programación utilizado.

Al ejecutarse un programa así programado, se iniciará con el código correspondiente a

su ejecución y luego el programa esperará a que ocurra un evento. Al ocurrir este, se

ejecutará el código correspondiente al evento que se realizó.

Visual Basic es un buen ejemplo de programación orientada a eventos.

9. Instancia: Una instancia es el término de POO para las variables. Crear una instancia de una

clase es lo mismo que crear una variable del tipo de datos que define la clase. Igual

que con las variables normales, también puedes crear varias instancias de la misma

clase.

10. Abstracción:

Es el principio de ignorar aquellos aspectos de un fenómeno observado que no son

relevantes, con el objetivo de concentrarse en aquellos que si lo son. Una abstracción

denota las características esenciales de un objeto que lo distingue de otras clases de

objetos. Decidir el conjunto correcto de abstracciones de un determinado

dominio, es el problema central del diseño orientado a objetos.

11. Herencia: La herencia básicamente consiste en que una clase puede heredar sus variables y

métodos a varias subclases

12. Interfaces:

Como se ha visto, los objetos definen su interacción con el mundo exterior con los

métodos que exponen o se definen. Los métodos forman el interfaz del objeto con el

mundo exterior; por ejemplo, los botones en el frente de un televisor, son el interfaz

entre el televidente y el cableado eléctrico en el otro lado de la cubierta plástica.

13. Paquetes:

Un paquete es un espacio que organiza un sistema de clases y de interfaces

relacionadas.

14. Polimorfismo:

Una de las características fundamentales es el polimorfismo, que no es otra cosa que

la posibilidad de construir varios métodos con el mismo nombre, pero con relación a la

clase a la que pertenece cada uno, con comportamientos diferentes. Esto conlleva la

habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos objetos

recibirían el mismo mensaje global pero responderían a él de formas diferentes.

15. Encapsulamiento o encapsulación: El encapsulamiento consiste en unir en la Clase las características y comportamientos,

esto es, las variables y métodos. Es tener todo esto es una sola entidad. En los

lenguajes estructurados esto era imposible.

16. Envió de mensajes: Los objetos de un programa interactúan y se comunican entre ellos por medio de

mensajes. Cuando un objeto A quiere que otro objeto B ejecute una de sus funciones

miembro (métodos de B), el objeto A manda un mensaje al objeto B.

17. Asociaciones: asociación tiene diversas interpretaciones en OO. En primer lugar puede hacer

referencia a la clase Asociación, que actúa como clase "intermedia" entre dos clases A

y B donde la pruralidad entre éstas tiene la forma (*, *) (muchos, muchos). Se podría

hacer cierta analogía con la teoría de base de datos en donde la tabla intermedia

permite romper la relación (M, M).

Por otro lado una asociación puede referirse a un simple vínculo entre una clase y otra,

o dicho de otro modo: una relación. Hay diferentes tipos de asociaciones, todas hacen

referencia a una relación semántica que vincula a las instancias de cada clase.

Generalmente se suele etiquetar estas asociaciones con un nombre (lo que se conoce

como rol). Las relaciones típicas son: "es parte de", "está contenido en", "es una

descripción de", "conoce a", "utiliza/gestiona a".

Por ejemplo: Motor es parte de Auto.

18. Agregación: Es una relación que se derivó de la asociación, por ser igualmente estructural, es decir

que contiene un atributo, que en todos los casos, será una colección, es decir un Array,

Vector, Collections, etc, y además de ello la clase que contiene la colección debe tener

un método que agregue los elementos a la colección. También se puede leer como que

un medio de transporte

19. Que es el OMG: Es un consorcio dedicado al cuidado y el establecimiento de diversos estándares de

tecnologías orientadas a objetos, tales como UML, XMI, CORBA. Es una organización

sin ánimo de lucro que promueve el uso de tecnología orientada a objetos mediante

guías y especificaciones para las mismas. El grupo está formado por diversas

compañías y organizaciones con distintos privilegios dentro de la misma.

20. Asociaciones y Clases de Asociaciones:

Una asociación puede modelarse como una clase; en ese caso, cada enlace se

convierte en una instancia de la clase.

Es útil modelar una asociación como una clase cuando los enlaces pueden

participar en asociaciones con otros objetos o cuando los enlaces están

sometidos a operaciones.

Una asociación que contiene atributos sin participar en relaciones con

otras clases se llama asociación atribuida.

El atributo de un enlace es una propiedad de los enlaces de una

asociación, que no se puede asociar a los objetos relacionados por el

enlace.

21. Multiplicidad: La multiplicidad especifica el número de instancias de una clase que pueden estar

relacionadas con una única instancia de una clase asociada.

22. Asociaciones Calificadas:

Una asociación calificada es una asociación en la cual los

objetos en el rol de “muchos” se pueden identificar de forma no ambigüa

mediante un atributo denominadocalificador.

Un calificador actúa como un selector entre los objetos reduciendo la

multiplicidad efectiva de “muchos” a “uno”.

Una asociación calificada con una multiplicidad “uno” o“cero o uno” especifica

un camino preciso para encontrar el objeto destino a partir del objeto fuente.

23. Asociaciones Reflexivas: Las asociaciones reflexivas son un tipo de asociación binaria en el cual la clase de

origen y destino de la asociación es la misma. Como ejemplo típico, trataremos la

organización de una empresa, definida mediante la relación “es responsable de” entre

instancias de la clase Empleado.

24. Generalización: De todas las relaciones posibles entre las distintas clases y objetos, hay que destacar

por su importancia en la relación de herencia. La relación de herencia es una relación

entre clases que comparten su estructura y el comportamiento.

25. Dependencias: Una dependencia puede indicar la utilización de un objeto de una clase como

argumento de una operación de otra o en su implementacion.

26. Composiciones:

En caso contrario, la composición es un tipo de relación dependiente en dónde un

objeto más complejo es conformado por objetos más pequeños. En esta situación, la

frase “Tiene un”, debe tener sentido:

El auto tiene llantas

La portátil tiene un teclado

27. Visibilidad:

capacidad de restringir el acceso a atributos y servicios de un objeto. Particularmente

importante en el diseño e implementación. (ej.: público / protegido / privado).

28. Ámbito:

el ámbito es el contexto que tiene un nombre dentro de un programa. El ámbito

determina en qué partes del programa una entidad puede ser usada.

29. Relaciones : Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto

relacionarse con aquellos que forman parte de la misma organización.

30. Agrupamiento: Básicamente es cuando tienes una clase padre estarías agrupando las clases hijos por

tener características parecidas, las que hacen que se hereden las mismas de una clase

padre.

31. Notación:

La notación debe ser un vehículo para capturar la forma de funcionar, el

comportamiento y la estructura de un sistema.

32. Extensión:

33. Envió de Mensajes: Los objetos de un programa interactúan y se comunican entre ellos por medio de

mensajes. Cuando un objeto A quiere que otro objeto B ejecute una de sus funciones

miembro (métodos de B), el objeto A manda un mensaje al objeto B.

34. Declaración de una clase y de un objeto:

Una clase es un molde del que luego se pueden crear múltiples objetos, con similares

características.

La clase define los atributos y métodos comunes a los objetos de ese tipo, pero luego, cada objeto tendrá sus propios valores y compartirán las mismas funciones. Debemos crear una clase antes de poder crear objetos (instancias) de esa clase. Al crear un objeto de una clase, se dice que se crea una instancia de la clase o un objeto propiamente dicho.

35. Operador ( . ): Se utiliza para navegar por las jerarquías de clips de película y acceder a variables,

propiedades o clips de película anidados (secundarios). El operador de punto se utiliza

también para probar o establecer las propiedades de un objeto o clase de nivel

superior, para ejecutar un método de un objeto o clase de nivel superior o para crear

una estructura de datos.

36. Diagrama de Clases :

Los diagramas de clase se usan en el diseño del modelo estático para ver un sistema.

Para las demás partes, este modelado involucra el vocabulario del sistema, el

modelado de colaboraciones, o modelado de esquemas. Los diagramas de clase son

también la base para un par de diagramas relacionados: Diagramas de Componente y

Diagramas de Instalación (Deployment).

37. Diagramas de objetos: representa la estructura estática del sistema mostrando los objetos (instancias) en el

sistema y las relaciones entre los objetos .

38. Diagramas de estados: Un Diagrama de Estados muestra la secuencia de estados por los que pasa un caso de

uso o un objeto a lo largo de su vida, indicando qué eventos hacen que se pase de un

estado a otro y cuáles son las respuestas y acciones que genera.

39. Diagramas de secuencia: Los diagramas de clases y los de objetos representan información estática. No obstante, en un sistema funcional, los objetos interactúan entre sí, y tales interacciones suceden con el tiempo. El diagrama de secuencias UML muestra la mecánica de la interacción con base en tiempos.

40. Diagrama de actividades: Sirven fundamentalmente para modelar el flujo de control entre actividades.

41. Diagrama de Colaboraciones: Un Diagrama de Colaboración muestra una interacción organizada basándose en los objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se Refiere). A diferencia de los Diagramas de Secuencia, los Diagramas de Colaboración muestran las relaciones entre los roles de los objetos. La secuencia de los mensajes y los flujos de ejecución concurrentes deben determinarse explícitamente mediante números de secuencia.

42. Diagrama de Componentes: Un diagrama de componentes muestra la organización y las dependencias entre un

conjunto de componentes.

43. Estereotipos:

Algunos sistemas requieren de elementos hechos a medida que no se encuentran en el

UML. Para ello, los estereotipos o clisés le permiten tomar elementos propios del UML

y convertirlos en otros que se ajusten a las necesidades. Se representan como un

nombre entre dos pares de paréntesis angulares. 44. Notas en diagrama de clases

Es frecuente que alguna parte del diagrama no presente una clara explicación del

porqué está allí o la manera en que trabaja. Cuando éste sea el caso, la nota UML será

útil. La nota tiene una esquina doblada y se adjunta al elemento del diagrama

conectándolo mediante una línea punteada.

Bibliografía http://es.wikipedia.org/wiki/ArgoUML

http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado

https://www.fdi.ucm.es/profesor/jpavon/poo/1.1.Objetos%20y%20Clases.pdf

http://www.aulaclic.es/macros-excel/t_2_1.htm

http://webdelprofesor.ula.ve/ingenieria/hyelitza/materias/programacion2/oxo/ProfaY

usneyi_Tema8_POOClasesyObjetos.pdf

http://aprendeenlinea.udea.edu.co/lms/moodle/file.php/561/Modulos/Modulo10._Pr

ogramacionOrientadaAObjetos.pdf

http://www.taringa.net/posts/info/11512703/Programacion-estructurada-orientada-

a-eventos-y-objetos.html

http://es.answers.yahoo.com/question/index?qid=20100119131755AAhBImS

http://apdaza-poo.blogspot.com/2007/09/conceptos-bsicos-de-poo.html

http://es.wikipedia.org/wiki/Object_Management_Group

http://www.ctr.unican.es/asignaturas/MC_OO/Doc/M_Estructural.pdf

http://informatica.uv.es/iiguia/DBD/Teoria/capitulo_2a.pdf

http://rua.ua.es/dspace/bitstream/10045/15995/1/POO-3-Herencia-10-11.pdf

http://programacioncolmayor3.blogspot.com/2013/02/dependencia-y-

asociacion.html

http://es.wikipedia.org/wiki/%C3%81mbito_(programaci%C3%B3n) http://www.monografias.com/trabajos/objetos/objetos.shtml#ixzz2wzzboesp

http://fpsalmon.usc.es/genp/doc/cursos/poo/metodo.html