El documento presenta una introducción a la programación orientada a objetos. Explica que un objeto es una "cosa" que existe en alguna realidad y que está compuesto de atributos y métodos. También define clases y objetos, y describe los pasos de la metodología orientada a objetos que incluyen análisis, diseño, implementación, pruebas y mantenimiento.
This presentation explains the major differences between SQL and NoSQL databases in terms of Scalability, Flexibility and Performance. It also talks about MongoDB which is a document-based NoSQL database and explains the database strutre for my mouse-human research classifier project.
This presentation explains the major differences between SQL and NoSQL databases in terms of Scalability, Flexibility and Performance. It also talks about MongoDB which is a document-based NoSQL database and explains the database strutre for my mouse-human research classifier project.
Domain Driven Design 기반의 마이크로서비스 디자인 방법론에 대해 설명을 하고 피보탈이 권장하는 모노리스 애플리케이션의 마이크로서비스 전환 방법론에 대해 살펴봅니다. 또한 실제 마이크로서비스 프로젝트에서 발생할 수 있는 우려사항들에 대해서도 국내 프로젝트 경험을 바탕으로 짚어봅니다.
Java Database Connectivity (JDBC) es una interfase de acceso a bases de datos estándar SQL que proporciona un acceso uniforme a una gran variedad de bases de datos relacionales.
Esta es la segunda entrega de una curso de Web Semántica. Trata zobre XML y RDF. Existen algunos ejemplos que se subiran por video. BLOG (http://manzamb.wordpress.com/) o Curso (http://pis.unicauca.edu.co/moodle/course/view.php?id=403)
Microservices Pattern Language
Microservices Software Architecture Governance, Best Practices and Design Pattern
Decomposition Patterns
Decompose by Business Capability
Decompose by Subdomain
Presentation slides from sessions discussing Event Source data storage and read-model projections.
Source code from demos at: https://bitbucket.org/csharpfritz/nerddinner-cqrs
One of the most challenging tasks when developing an ADF application is achieving a proper layout. Both
stretching components and the ones that don't stretch can make a developer's life into a nightmare. In this
session you will learn best practices for creating complex layouts with ADF Faces. You will see how to use the
various ADF Layout components and build the layout that you need.
Benchmarking is hard. Benchmarking databases, harder. Benchmarking databases that follow different approaches (relational vs document) is even harder.
But the market demands these kinds of benchmarks. Despite the different data models that MongoDB and PostgreSQL expose, many organizations face the challenge of picking either technology. And performance is arguably the main deciding factor.
Join this talk to discover the numbers! After $30K spent on public cloud and months of testing, there are many different scenarios to analyze. Benchmarks on three distinct categories have been performed: OLTP, OLAP and comparing MongoDB 4.0 transaction performance with PostgreSQL's.
What would be faster, MongoDB or PostgreSQL?
Domain Driven Design 기반의 마이크로서비스 디자인 방법론에 대해 설명을 하고 피보탈이 권장하는 모노리스 애플리케이션의 마이크로서비스 전환 방법론에 대해 살펴봅니다. 또한 실제 마이크로서비스 프로젝트에서 발생할 수 있는 우려사항들에 대해서도 국내 프로젝트 경험을 바탕으로 짚어봅니다.
Java Database Connectivity (JDBC) es una interfase de acceso a bases de datos estándar SQL que proporciona un acceso uniforme a una gran variedad de bases de datos relacionales.
Esta es la segunda entrega de una curso de Web Semántica. Trata zobre XML y RDF. Existen algunos ejemplos que se subiran por video. BLOG (http://manzamb.wordpress.com/) o Curso (http://pis.unicauca.edu.co/moodle/course/view.php?id=403)
Microservices Pattern Language
Microservices Software Architecture Governance, Best Practices and Design Pattern
Decomposition Patterns
Decompose by Business Capability
Decompose by Subdomain
Presentation slides from sessions discussing Event Source data storage and read-model projections.
Source code from demos at: https://bitbucket.org/csharpfritz/nerddinner-cqrs
One of the most challenging tasks when developing an ADF application is achieving a proper layout. Both
stretching components and the ones that don't stretch can make a developer's life into a nightmare. In this
session you will learn best practices for creating complex layouts with ADF Faces. You will see how to use the
various ADF Layout components and build the layout that you need.
Benchmarking is hard. Benchmarking databases, harder. Benchmarking databases that follow different approaches (relational vs document) is even harder.
But the market demands these kinds of benchmarks. Despite the different data models that MongoDB and PostgreSQL expose, many organizations face the challenge of picking either technology. And performance is arguably the main deciding factor.
Join this talk to discover the numbers! After $30K spent on public cloud and months of testing, there are many different scenarios to analyze. Benchmarks on three distinct categories have been performed: OLTP, OLAP and comparing MongoDB 4.0 transaction performance with PostgreSQL's.
What would be faster, MongoDB or PostgreSQL?
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon KoudsiRaimonKoudsi
En esta presentacion se tratará de: FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS, asi como los FUNDAMENTOS BASICOS DEL DISEÑO ORIENTADO A OBJETOS
Presentación realizada dentro del marco del diplomado de Diseño de Interacción y Physical Computing 2013 de la UDD.
Contempla una revisión general de conceptos, una mirada a las metodologías Waterfall y Agile, una revisión de los principales entregables del UCD, una compilación de Principios de interacción y una introducción a las etapas de prototipado y testing
Instrucciones del procedimiento para la oferta y la gestión conjunta del proceso de admisión a los centros públicos de primer ciclo de educación infantil de Pamplona para el curso 2024-2025.
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