Guillermo Villafaña Rodríguez

Programación Orientada a Objetos

Instituto Tecnológico de Celaya

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.

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.

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

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

Características de 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.

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

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

UML

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.

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

• 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

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.

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.

+ Indica propiedades / métodos públicos

# Indica propiedades / métodos protegidos

- Indica propiedades / métodos privados

Representación de una clase:

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

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)

Ejemplo Cardinalidad :

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

, de Generalización.

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

Alternativas para mostrar Agregación por Composición

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

Asociación.

Muchas clases pueden estar asociadas a una misma clase

Asociaciones formadas por clases que se relacionan en forma alternativa

Para una misma clase puede existir una asociación recursiva

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 hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operación y los

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.

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.

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.

Diagramas de componentesPuede 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.

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