2. Programación Orientada a Objetos
• Una técnica o estilo de programación que utiliza objetos
como bloque esencial de construcción de software.
• Los lenguajes de programación Orientados a Objetos
pretenden construir programas basándose en los
objetos presentes en la realidad correspondiente al
programa que se desea construir.
• Por esa razón es que permiten crear en la computadora
representaciones de esos objetos de la realidad.
3. ¿Qué es un objeto?
• Un Objeto es una "cosa", real o imaginaria, física o
intangible, viva o inerte que existe enmarcado en
alguna realidad.
• Estamos rodeados por objetos, las personas que nos
rodean son objetos, los muebles de nuestra casa son
objetos e incluso en alguna realidad emocional
podemos decir que cosas como los pensamientos o
los sentimientos son objetos.
4. ¿Qué es un objeto?
• Un objeto puede, por tanto, ser algo conceptual o
algo físico.
• La idea fundamental es que un objeto es una entidad
(o noción) única.
• Cada objeto es una individualidad, que puede estar
relacionado o constituido por otros objetos.
5. ¿Qué es un objeto?
• Dentro del paradigma de la Orientación a Objetos, se
entiende que los objetos se componen de dos
elementos denominados atributos y métodos.
• Los primeros son aquellos datos del objeto con los
cuales interese trabajar dentro de una determinada
realidad
• Los segundos son las acciones u operaciones que
trabajan sobre el objeto.
6. ¿Qué es un objeto?
• Por ejemplo, si consideramos a una cuenta bancaria
como un objeto, sus atributos de interés podrían ser
su número, la cédula de su dueño y el monto de
dinero que almacena, mientras que sus métodos
podrían ser las operaciones de depósito, retiro y
consulta.
7. ¿Qué es un objeto?
• Desde un punto de vista más formal, un objeto es en
realidad un elemento perteneciente a un determinado
Tipo.
• Así como tenemos elementos que son enteros o
Cadenas de Texto (int o String) podemos crear
nuestros tipos particulares
8. Clases de Objetos
• Desde un punto de vista conceptual, diremos que
una Clase es una plantilla o molde imaginario que
sirve para definir objetos.
• Decimos que los objetos de una clase son instancias
de la misma.
9. Clases de Objetos
• Podemos hacer la siguiente analogía:
• La clase es como el plano de un edificio
• los objetos son todos los edificios concretos que
yo puedo construir con ese plano.
10. Clases y Objetos
• Por otra parte, no podemos dejar de mencionar una
característica muy importante de los objetos: poseen
identidad.
• Si bien los objetos de una clase tienen todos las
mismas características, cada uno de ellos es una
entidad única y diferenciable de los demás.
11. Clases y Objetos
• Por ejemplo, la clase persona define tres atributos:
cédula, nombre y domicilio
• Todos los objetos de la clase tendrán una cédula, un
nombre y un domicilio.
• No obstante, cada objeto de la clase persona será
único, porque los valores que tomen esos datos para
cada objeto en concreto nunca serán todos los
mismos.
12. Clases y Objetos
• La existencia de clases de objetos es una
característica sumamente útil y necesaria a la hora
de escribir programas Orientados a Objetos.
• Nos permite manipular con facilidad grandes grupos
de Objetos.
• Sería muy difícil tener que programar cada Objeto
por separado.
13. Clases y Objetos
• Una clase es pues, un tipo de datos definido por el
programador, que determina las estructuras de datos
y las operaciones asociadas con ese tipo.
• Cada clase es un modelo que describe un infinito
conjunto de objetos del mismo tipo.
14. Clases y Objetos
• Cada vez que se construye un objeto de una clase,
se crea una instancia de esa clase.
• Cada instancia u objeto de una clase tiene su propio
valor para cada uno de sus atributos pero comparte
los mismos métodos que todos los otros objetos de
la misma clase.
16. Metodología Orientada a Objetos
• A la hora de modelar sistemas utilizando
Programación Orientada a Objetos, seguiremos una
metodología para resolver problemas que se divide
en las siguientes etapas.
1.Análisis del sistema.
2.Diseño del sistema.
17. Metodología Orientada a Objetos
• A la hora de modelar sistemas utilizando
Programación Orientada a Objetos, seguiremos una
metodología para resolver problemas que se divide
en las siguientes etapas.
3. Implementación del sistema en un lenguaje
Orientado a Objetos.
4. Prueba, despliegue y mantenimiento
del sistema
18. 1- Análisis del Sistema
• Determinar cuál es el propósito general del Sistema,
qué aspectos abarcará y cuáles no.
• Partiendo de los requerimientos del sistema (tareas
concretas que se espera que el mismo resuelva),
debemos estudiar aquellos aspectos de la realidad
correspondiente que sean relevantes para la
resolución de los requerimientos y construir un
Modelo de Análisis que los represente.
19. 1 - Análisis del Sistema
• Esto se hace con el fin de contextualizar hasta dónde
debe abarcar el Sistema y qué cosas no interesan y
deben quedar afuera del mismo.
• La construcción del modelo de análisis se hace
identificando los Objetos presentes en la realidad
que son relevantes y cómo se relacionan entre sí,
dejando afuera a todos aquellos que no son de
importancia.
20. 2 - Diseño del Sistema
• Esta etapa consiste en traducir el modelo generado
durante el análisis en un conjunto de clases y
métodos que permitan implementar el Sistema de
forma tal que resuelva los requerimientos que fueron
definidos para el mismo.
21. 2 - Diseño del Sistema
• Esto significa generar una documentación lo más
clara posible de las clases que hay que programar y
de los métodos que hay que implementar en ellas.
Para generar dicha documentación, se usará la
notación UML, al igual que en la etapa de análisis
22. 3 - Implementación del Sistema
• Esta etapa consiste en partir de la documentación
generada en la etapa del diseño e implementar en un
lenguaje de Programación Orientado a Objetos cada
una de las Clases especificadas durante el diseño,
definiendo estructuras de datos apropiadas para
cada una de ellas, así como los métodos de cada
clase, también especificados durante el diseño.
23. 3 - Implementación del Sistema
• Todos los lenguajes OO proveen mecanismos para
implementar Clases y Objetos, además de garantizar
el cumplimiento de los cuatro conceptos
fundamentales (abstracción, encapsulamiento,
herencia y polimorfismo)
24. 4 - Prueba, despliegue y mantenimiento
• Una vez que hemos construido el sistema, que
hemos traducido el modelo a un lenguaje Orientado a
Objetos determinado, y antes de liberarlo al público o
entregarlo al cliente que nos lo pidió, debemos hacer
pruebas extensivas que verifiquen que el sistema
funciona de la manera esperada y realiza las tareas
especificadas.
25. 4 - Prueba, despliegue y mantenimiento
• Después de todo esto es posible entregar el
producto y luego sigue el mantenimiento, mediante
el cual vamos a corregir pequeños inconvenientes o
hacer cambios que le permitan evolucionar,
incorporar nuevas cosas.
• Un programa bien diseñado, bien analizado, permite
que los cambios sean razonables.
27. Identificación y Análisis de Requerimientos
• Lo primero que necesitamos para resolver el
problema es establecer cuál es el problema en sí.
• Tenemos que conocer qué es lo que necesitamos
que el programa haga con exactitud.
28. Identificación y Análisis de Requerimientos
• Comienza recabando información sobre el problema
• Sigue con un análisis exhaustivo de esa información
• Termina con un documento llamado Especificación
de Requerimientos (ESRE).
29. ¿Cómo obtener la información?
• Especificación Inicial del cliente
• No siempre es precisa
• Puede tener omisiones (faltar información sobre el
negocio)
30. ¿Cómo obtener la información?
• Expertos en la materia
• Se puede obtener información sobre el problema
(negocio) a resolver consultando a expertos en la
materia
• Habitualmente son provistos por el cliente y no
tienen, necesariamente, que saber de informática
31. ¿Cómo obtener la información?
• Usuarios
• Son las personas que van a usar el sistema
• Dan información práctica en contraposición con la
teórica obtenida anteriormente
32. ¿Cómo obtener la información?
• Gerentes:
• Son los responsables del sistema
• Definen la importancia de cada parte del mismo
33. ¿Cómo obtener la información?
• Marketing:
• Nos puede llegar a ayudar a investigar si hay
mercado para productos similares. De ser así se
puede considerar la idea de hacer un framework o
componentes reusables para proyectos similares
• ™Si el proyecto es interno, se debe discutir con otros
departamentos el hacer un framework o
componentes reusables
34. ¿Cómo obtener la información?
• Proyectos previos:
• Pueden darnos información muy valiosa tanto
positiva como negativa (tomar las positivas y evitar
las negativas)
35. Especificación de requerimientos (ESRE)
• Es un documento que describe claramente los
requerimientos funcionales (del cliente) y no
funcionales (del sistema)
• El aporte del cliente es crítico para este documento
• Debe usar la terminología del negocio
• Debe tener oraciones claras, completas y poca
terminología informática (jerga)
36. Especificación de requerimientos (ESRE)
• Contiene detalle acerca del alcance del proyecto
• Explica el contexto del problema
• Debe contener toda la información pertinente para el
análisis y diseño del proyecto
• Hace explícitas todas las restricciones necesarias
37. Especificación de requerimientos (ESRE)
• Estándar IEEE 830.
• Establece claramente qué cosas debe contener una
especificación de requerimientos, cómo debe estar
constituido
• Si queremos participar de licitaciones del gobierno o
grandes empresas, debe seguir este estándar
38. Especificación de requerimientos (ESRE)
• Definición de requerimiento [IEEE]
• Condición o capacidad de un sistema
requerida por el usuario para resolver un
problema o alcanzar un objetivo.
• Condición o capacidad que debe poseer un
sistema para satisfacer un contrato, estándar,
especificación, u otro documento formalmente
impuesto.
39. Especificación de requerimientos (ESRE)
• Requerimientos funcionales
• Especifican de los servicios que el sistema debe
proveer.
• Definen QUE hace el sistema.
• Describen todas las entradas y todas las salidas del
sistema y la forma en que se relacionan.
40. Especificación de requerimientos (ESRE)
• Requerimientos funcionales - Ejemplos:
• El sistema debe emitir un informe de estado de
situación patrimonial.
• El sistema debe realizar la liquidación de haberes a
personal contratado y personal estable.
41. Especificación de requerimientos (ESRE)
• Requerimientos funcionales - Ejemplos:
• El sistema debe capturar cualquier regla de
liquidación de haberes sin necesidad de intervención
del fabricante del producto.
• El sistema debe tener un archivo de movimientos.
42. Especificación de requerimientos (ESRE)
• Requerimientos no-funcionales
• Especifican restricciones o propiedades que el
sistema debe cumplir relacionadas con:
• Características de calidad
• Modelo de calidad ISO 9126
• Calidad interna, externa y en uso
43. Especificación de requerimientos (ESRE)
• Requerimientos no-funcionales
• Especifican restricciones o propiedades que el
sistema debe cumplir relacionadas con:
• Reglas de negocio
• Vocabulario y terminología del negocio
• Estándares y políticas organizacionales
44. Especificación de requerimientos (ESRE)
• Requerimientos no-funcionales
• Especifican restricciones o propiedades que el
sistema debe cumplir relacionadas con:
• Restricciones de entorno
• Hardware y software de base
• Interfaces externas
45. Especificación de requerimientos (ESRE)
• Requerimientos no-funcionales - Ejemplos:
• El sistema debe correr sobre Windows 7 o superior.
• El sistema debe ser fácil de aprender.
• El sistema debe estar desarrollado en Java SE.
• El sistema deberá ser desarrollado en 10 meses.
• El sistema debe encriptar los datos almacenados.
46. Especificación de requerimientos (ESRE)
• El estándar IEEE 830 establece centralmente que los
requerimientos deben tener las siguientes
características:
• Corrección: Todo requisito que se establezca en el
documento refleja una necesidad real.
47. Especificación de requerimientos (ESRE)
• El estándar IEEE 830 establece centralmente que los
requerimientos deben tener las siguientes
características:
• No ambiguos: No puede haber doble interpretación
en lo que se refiere a lo que se va a desarrollar. Los
requisitos deben estar redactados en un lenguaje no
ambiguo y además, de ser posible, utilizando algún
esquema o lenguaje matemático.
48. Especificación de requerimientos (ESRE)
• El estándar IEEE 830 establece centralmente que los
requerimientos deben tener las siguientes
características:
• Completos: se deben incluir todas las posibilidades
de entrada y salida del sistema, tanto válidas como
no válidas.
49. Especificación de requerimientos (ESRE)
• El estándar IEEE 830 establece centralmente que los
requerimientos deben tener las siguientes
características:
• Consistentes: No podemos incluir requisitos
contradictorios, un requisito posterior no puede ir
contra lo establecido en un requerimiento anterior.
Uno de los dos debe corregirse.
50. Especificación de requerimientos (ESRE)
• El estándar IEEE 830 establece centralmente que los
requerimientos deben tener las siguientes
características:
• Verificables: Debe existir un modo económico de
verificar si un requisito se cumple o no.
51. Especificación de requerimientos (ESRE)
• El estándar IEEE 830 establece centralmente que los
requerimientos deben tener las siguientes
características:
• Modificables: Una Especificación de Requerimientos
solo puede ser modificable si sus requisitos están
estructurados de forma que los cambios puedan
realizarse de forma fácil, completa y consistente.
52. Especificación de requerimientos (ESRE)
• El estándar IEEE 830 establece centralmente que los
requerimientos deben tener las siguientes
características:
• Trazables: Tenemos que saber quién nos pidió el
requisito, tenemos que establecer de antemano con
el cliente quién de la empresa va a poder pedir
cosas. Tiene que haber responsables.
54. Identificación de Clases y Objetos
• A partir de la descripción del problema a resolver
• Se subrayan los sustantivos y las frases sustantivas
• Todas las palabras subrayadas son candidatas a ser
objetos y clases
• Los sinónimos se ponen juntos
55. Identificación de Clases y Objetos
• Para identificar objetos de un programa dividiremos los
mismos en una serie de categorías base, aunque podrían
usarse otras categorías diferentes en función de los
requisitos de la aplicación/programa a diseñar:
• Cosas tangibles: avión, televisor, coche, etc.
56. Identificación de Clases y Objetos
• Para identificar objetos de un programa dividiremos los
mismos en una serie de categorías base, aunque podrían
usarse otras categorías diferentes en función de los
requisitos de la aplicación/programa a diseñar:
• Roles o papeles desempeñados por personas:
gerente, cliente, médico, etc
57. Identificación de Clases y Objetos
• Para identificar objetos de un programa dividiremos los
mismos en una serie de categorías base, aunque podrían
usarse otras categorías diferentes en función de los
requisitos de la aplicación/programa a diseñar:
• Organizaciones: empresa, división, equipo, etc.
58. Identificación de Clases y Objetos
• Para identificar objetos de un programa dividiremos los
mismos en una serie de categorías base, aunque podrían
usarse otras categorías diferentes en función de los
requisitos de la aplicación/programa a diseñar:
• Incidentes que representan un suceso: vuelo,
accidente, suceso, etc
59. Identificación de Clases y Objetos
• Para identificar objetos de un programa dividiremos los
mismos en una serie de categorías base, aunque podrían
usarse otras categorías diferentes en función de los
requisitos de la aplicación/programa a diseñar:
• Interacciones que implican transición o contrato y
relacionan dos o más objetos del modelo: compras,
matrimonio, etc.
60. Identificación de Clases y Objetos
Ejercicio:
1. El cliente nos pide un sistema que le permita gestionar su empresa
de transporte. La misma dispone de camiones, camionetas y motos
que realizan entregas que le piden los clientes. La empresa dispone
de dos estacionamientos, en los que permanecen los vehículos
cuando no están realizando alguna entrega, que también tienen que
ser gestionados, porque no caben todos ellos en los terrenos, por lo
que debe contratar espacio en estacionamientos privados. Además,
el sistema debe gestionar la plantilla de choferes, asignándolos a los
vehículos.
61. Identificación de Clases y Objetos
Ejercicio:
2. Nuestra empresa ha decidido comenzar el desarrollo de un juego
multiplataforma en el que los jugadores se encuentran frente a un
tablero lleno de bolillas de colores, habrá tableros de diferentes
tamaños y formas y las bolillas pueden ser de seis colores
diferentes. Los jugadores deben combinar al menos tres bolillas del
mismo color moviendo una bolilla. Los movimientos permitidos son
horizontal y vertical únicamente. Cada tablero deberá resolverse en
una cantidad de movimientos determinada, generando puntos por la
cantidad de movimientos realizados.
62. Identificación de Clases y Objetos
Ejercicio:
3. En la veterinaria del vecino han decidido implementar un sistema
que le ayude a realizar la gestión de las consultas a los animales que
atienden a diario. Cada cliente tiene uno o varios animales, que
pueden ser de diferentes especies y razas. Cada vez que se atiende
a un paciente se produce una consulta, esta consulta puede ser
programada o de urgencia, teniendo cada tipo de consulta un costo
diferente. La veterinaria dispone de tres médicos que atienden en
los dos consultorios, teniendo ellos horarios rotativos.
63. Identificación de Clases y Objetos
• Para identificar objetos de un programa dividiremos los
mismos en una serie de categorías base, aunque podrían
usarse otras categorías diferentes en función de los
requisitos de la aplicación/programa a diseñar:
• Lugares: sala de embarque, muelle de carga,
almacén, etc.
64. Identificación de Atributos y Métodos de clase
• Una vez que “tenemos en claro” los objetos que van a
formar parte de nuestro programa (pueden variar a
medida que empecemos con el diseño más profundo),
hemos de identificar los atributos de dichos objetos que
nos van a ser útiles.
• Los atributos describen la abstracción de características
individuales que poseen todos los objetos.
65. Identificación de Atributos y Métodos de clase
• En una clase Empleado, podríamos tener:
• Número de cédula
• Nombre y apellido (¿separados o juntos?)
• Horario (entrada, salida, descanso)
• Sueldo
66. Identificación de Atributos y Métodos de clase
• Por último nos quedaría la tarea de identificar las
operaciones o funciones miembro las cuales van a
cambiar, de alguna forma, el comportamiento del objeto.
• Cambian los valores de uno o más atributos contenidos
en dicho objeto.
67. Identificación de Atributos y Métodos de clase
• La identificación de las operaciones se realiza haciendo
un nuevo análisis gramatical de la descripción del
problema y buscando y aislando los verbos presentes en
el texto.
• “El sistema deberá permitir incrementar el salario de
cada empleado de acuerdo a lo establecido en los
acuerdos salariales del sector”
68. Identificación de Atributos y Métodos de clase
• Las operaciones generalmente se dividen en los
siguientes tres grandes grupos:
• Manipulación de datos: de alguna forma específica
como añadir, borrar, cambiar formato, etc. (setters)
• cambiar horario
• aumentar salario
69. Identificación de Atributos y Métodos de clase
• Las operaciones generalmente se dividen en los
siguientes tres grandes grupos:
• Monitorización del objeto: comprobarán el estado de
un objeto frente a la ocurrencia de algún suceso de
control. (getters)
• obtener salario
• obtener cédula
70. Identificación de Atributos y Métodos de clase
• Las operaciones generalmente se dividen en los
siguientes tres grandes grupos:
• Realización de cálculos: estos métodos realizarán
operaciones de muy diversa índole (algebraicas,
estadísticas, etc.) sobre los atributos de un objeto.
• cambiar horario
• depositar salario
