1. Guillermo Villafaña Rodríguez
Programación Orientada a Objetos
Instituto Tecnológico de
Celaya

2. Programa que al introducir dos números realice las
operaciones matemáticas que una calculadora, las cuales
son suma, resta, multiplicación y división.

7. Concepto de patrón
• Un patrón es la abstracción de una forma concreta que puede
repetirse en contextos específicos.
• Un patrón es una unidad de información nombrada, instructiva e
intuitiva que captura la esencia de una familia exitosa de
soluciones probadas a un problema recurrente dentro de un
cierto contexto.

8. • Programar no significa colocar líneas al azar y ver si se obtienen los resultados
requeridos. Tampoco significa concebir una solución partiendo desde cero.
Siempre se reutilizan elementos de programas conocidos. Es así como al
estudiar los programas se pueden observar patrones de organización de las
instrucciones que se repiten una y otra vez. Estas instrucciones rara vez son
idénticas, pero exhiben ciertas similitudes, que denominaremos patrones de
programación.

9. • Es importante conocer estos patrones de programación porque son muy útiles para
concebir nuevos programas. Ellos resuelven problemas conocidos sin tener que re-
inventar soluciones para esos problemas una y otra vez.
• Un ejemplo de estos patrones de programación es la acumulación. Este patrón se
usa para realizar cálculos como la suma de varios valores calculados en las
iteraciones de un ciclo:
• suma= val1 + val2 + val3 + ... + valn
• producto= fac1 * fac2 * fac3 * ... * facn
• Iteraciones: se refiere a la acción de repetir una serie de pasos un cierto número de
veces.

10. Característicasde los patrones de
programación
• Hay que tener en cuenta que no todas las soluciones que
tengan las características de un patrón son un patrón, sino
que debe probarse que es una solución a un problema que
se repite.
• Para que se pueda considerar un patrón, éste debe pasar
por unas pruebas que reciben el nombre de test de
patrones.
• Mientras tanto esa solución recibe el nombre de proto-
patrón.

11. • Los patrones indican repetición, si algo no se repite, no es
posible que sea un patrón. Pero la repetición no es la única
característica importante. También necesitamos mostrar que un
patrón se adapta para poder usarlo, y que es útil. La repetición es
una característica cuantitativa pura, la adaptabilidad y utilidad son
características cualitativas. Podemos mostrar la repetición
simplemente aplicando la regla de tres (en al menos tres sistemas
existentes); mostrar la adaptabilidad explicando como el patrón
es exitoso; y mostrar la utilidad explicando porque es exitoso y
beneficioso.

12. • Un patrón debe ser útil porque enseña como el patrón que
tenemos en nuestra mente puede ser transformado en una
instancia del patrón en el mundo real, como una cosa que añade
valor a nuestra vida como diseñadores. Un patrón debe ser
también utilizable porque muestra como un patrón descrito de
una forma literaria puede ser transformado en un patrón que
tenemos en nuestra mente. Y un patrón debe ser usado porque
es como los patrones que existen en el mundo real llegan a ser
documentados como patrones de una forma literaria.

13. UML

14. UML
• El lenguaje unificado de diagrama sirve para especificar, visualizar
y documentar esquemas de sistemas de software orientado a
objetos.
• UML no es un método de desarrollo, lo que significa que no
sirve para determinar qué hacer en primer lugar o cómo diseñar
el sistema, sino que simplemente le ayuda a visualizar el diseño y
a hacerlo más accesible para otros.

15. • UML está controlado por el grupo de administración de objetos
(OMG) y es el estándar de descripción de esquemas de software.
El OMG (de sus siglas en inglés Grupo de Gestión de
Objetos) 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.

16. • UML se compone de muchos elementos de esquematización que
representan las diferentes partes de un sistema de software
~ Diagrama de casos de uso
~ Diagrama de clases
~ Diagrama de secuencia
~ Diagrama de colaboración
~ Diagrama de estado
~ Diagrama de actividad
~ Diagrama de componentes
~ Diagrama de implementación
~ Diagrama de relaciones de entidad

17. Diagrama de casos de uso
• Los diagramas de casos de uso describen las relaciones
y las dependencias entre un grupo de casos de uso y los
actores participantes en el proceso.
• Los diagramas de casos de uso sirven para facilitar la
comunicación con los futuros usuarios del sistema, y
resultan especialmente útiles para determinar las
características necesarias que tendrá el sistema. En otras
palabras, los diagramas de casos de uso
describen qué es lo que debe hacer el sistema, pero
no cómo.

19. Diagrama de clases
• Los diagramas de clases muestran las diferentes clases que componen un sistema y
cómo se relacionan unas con otras.
• Son diagramas “estáticos” porque muestran las clases, junto con sus métodos y
atributos, así como las relaciones estáticas entre ellas: qué
clases “conocen” a qué otras clases o qué clases “son parte” de otras clases, pero
no muestran los métodos mediante los que se invocan entre ellas.
• Las clases están representadas por rectángulos, con el nombre de la clase, y también
pueden mostrar atributos y métodos de la clase en otros dos “compartimentos” dentro
del rectángulo.
• Los propiedades se muestran al menos con su nombre, y también pueden mostrar su
tipo, valor inicial y otras propiedades.
• Los métodos también se muestran al menos con su nombre, y pueden mostrar sus
parámetros y valores de retorno.

21. + Indica propiedades / métodos públicos
# Indica propiedades / métodos protegidos
- Indica propiedades / métodos privados
Representación de una clase:

22. En un diagrama de clases, los vínculos entre clases se representan por líneas. A las que
se les de diferentes características dependiendo del tipo de relación.
Adicionalmente, en los extremos de estas líneas, puede colocarse la descripción del Rol
que asume cada clase en esa relación

23. También en los extremos de la línea, se coloca la Cardinalidad, que describe cuántos
objetos de cada clase pueden participar en la relación.(mínimo..máximo)
La Cardinalidad de una relación puede ser:
 - Ninguno o Muchos 0..* o * o (0..n)
 - Uno o muchos 1..* o (1..n)
 - Exactamente uno 1 o (1)
 - Un número fijo m o (m)
 - Un numero variable 2..6 o (2..6)

24. Ejemplo Cardinalidad :

25. Entre dos clases puede existir una relación de Herencia o, en la terminología de UML
, de Generalización.

26. - Cuando una clase es parte o componente de otra
clase se le denomina Agregación.

28. Alternativas para mostrar Agregación por Composición

29. - Si existe un vínculo entre los objetos de las clases se denomina relación de
Asociación.

30. Muchas clases pueden estar asociadas a una misma clase

31. Asociaciones formadas por clases que se relacionan en forma alternativa

32. Para una misma clase puede existir una asociación recursiva

33. Diagramas de
secuencia
Los diagramas de secuencia muestran el intercambio de mensajes
(es decir la forma en que se invocan) en un momento dado. Los
diagramas de secuencia ponen especial énfasis en el orden y el
momento en que se envían los mensajes a los objetos.
En los diagramas de secuencia, los objetos están representados por
líneas intermitentes verticales, con el nombre del objeto en la parte
más alta. El eje de tiempo también es vertical, incrementándose

35. Diagramas de
colaboración
Los diagramas de colaboración muestran las interacciones que ocurren
entre los objetos que participan en una situación determinada. Esta es más
o menos la misma información que la mostrada por los diagramas de
secuencia, pero destacando la forma en que las operaciones se producen en
el tiempo, mientras que los diagramas de colaboración fijan el interés en las
relaciones entre los objetos y su topología.

36. Diagramas de estado
Los diagramas de estado describen gráficamente los eventos y los estados de
los objetos. Los diagramas de estado son útiles, entre otras cosas, para
indicar los eventos del sistema en los casos de uso.

37. Diagramas de actividades
Los diagramas de actividad describen la secuencia de las actividades en un
sistema. Los diagramas de actividad son una forma especial de los
diagramas de estado, que únicamente (o mayormente) contienen
actividades.

38. Diagramas de componentes
Puede usar un diagrama de componentes para describir un diseño que se
implemente en cualquier lenguaje o estilo. Solo es necesario identificar los
elementos del diseño que interactúan con otros elementos del diseño a
través de un conjunto restringido de entradas y salidas. Los componentes
pueden tener cualquier escala y pueden estar interconectados de cualquier
manera.

39. Bibliografia
Microsoft Developer Network
Desarrollar modelos para el diseño de software:
http://msdn.microsoft.com/es-es/library/dd409436.aspx
KDE Documentation
http://docs.kde.org/stable/es/kdesdk/umbrello/uml-
elements.html#state-diagram