Programa de
Ingeniería de
Sistemas
Programaci
ón
Orientada a
Objetos
Sesión 8
Tema:
GRASP parte 2
Resultado de aprendizaje Evidencia de aprendizaje
Construye programas usando conceptos básicos de Informes académicos individuales de
programación orientada a Objetos. GRASP
Contenido
Relaciones entre clases y
principios básicos
• Bajo acoplamiento
• Alta cohesión
• Controlador
• Notación gráfica con UML
(diagrama de clases)
Revisa el
siguiente
video:
Después de haber visualizado el video en la slide
anterior, reflexionamos y respondemos las
siguientes interrogantes:
01 ¿Qué han visto? ¿Qué opinan?
02 ¿Cómo es el Bajo Acoplamiento y Alta Cohesión que
observa en el video?
¿Actualmente de qué manera es el Bajo Acoplamiento y
03 Alta Cohesión?
Tema
GRASP parte
2:
Programación Orientada a Objetos– Sesión 8
Introducción
El modelo–vista–controlador (MVC) fue desarrollado en el Centro de
Investigaciones Xerox Corporation a finales de los años setenta en
California por Trygve Reenskaug.
La arquitectura del patrón Modelo-Vista-Controlador es un
paradigma de programación bien conocido para el desarrollo de
aplicaciones con interfaz gráfica de usuario (GUI).
El MVC es un patrón de software que separa los componentes de
aplicación en tres niveles por sus diferentes responsabilidades.
Programación Orientada a Objetos– Sesión 8
Relación del MVC
Modelo
• Lógica de Negocio
Vista
• Interfaz de usuario
Controlador
• Lógica de Control
Programación Orientada a Objetos– Sesión 8
¿Por qué utilizar MVC?
La razón es que nos permite separar los componentes de nuestra
aplicación dependiendo de la responsabilidad que tienen, esto
significa que cuando hacemos un cambio en alguna parte de
nuestro código, esto no afecte otra parte del mismo.
Surge de la necesidad de crear software más robusto con un ciclo
de vida más adecuado, donde se potencie la reutilización del código
y la separación de conceptos, características que buscan facilitar la
tarea de desarrollo de aplicaciones y su posterior mantenimiento.
Programación Orientada a Objetos– Sesión 8
Ejemplo
Si modificamos nuestra Base de Datos, sólo deberíamos modificar el modelo
que es quién se encarga de los datos y el resto de la aplicación debería
permanecer intacta.
Esto respeta el principio de la responsabilidad única. Es decir, una parte de
tu código no debe de saber qué es lo que hace toda la aplicación, sólo debe
de tener una responsabilidad.
Programación Orientada a Objetos– Sesión 8
Diagrama de MVC
El Modelo
Programación Orientada a Objetos– Sesión 8
El modelo es la porción que implementa la “Lógica del
Negocio”.
Se le suele llamar a la parte del sistema que representa
objetos y sus interacciones del mundo real.
Son rutinas que realizan entradas de datos, consultas,
generación de informes y más específicamente todo el
procesamiento que se realiza detrás de la aplicación.
Las peticiones de acceso o manipulación de información llegan
al 'Modelo' a través del 'controlador’, y este envía a la 'vista'
aquella información que en cada momento se le solicita para
que sea mostrada (típicamente a un usuario).
El Modelo (cont.)
Es la capa donde se trabaja con los datos, por tanto
contendrá mecanismos para acceder a la información y
también para actualizar su estado. Los datos los tendremos
habitualmente en una base de datos, por lo que en los modelos
tendremos todas las funciones que accederán a las tablas y
harán los correspondientes selects, updates, inserts, etc.
Programación Orientada a Objetos– Sesión 8
El controlador
El controlador es el cerebro de la aplicación MVC.
Responde a eventos (acciones del usuario) e invoca peticiones
al “modelo” cuando se hace alguna solicitud sobre la
información. También puede enviar comandos a su “vista”
asociada si se solicita.
Empleado como un mediador entre el medio gráfico ("View") y
el modelo ("Model"), coordina las acciones que son llevadas
acabo entre ambos.
El controlador generalmente crea instancias y utiliza métodos
de esos modelos para conseguir los datos que se presentan a
los usuarios, enviándolos a la vista correspondiente.
Programación Orientada a Objetos– Sesión 8
La vista
● Las vistas son las porciones de la aplicación MVC que presentan
salida al usuario.
● Presenta el “modelo” (información y lógica de negocio) en un
formato adecuado para interactuar (interfaz de usuario).
● Ni el modelo ni el controlador se preocupan de cómo se verán
los datos, esa responsabilidad es únicamente de la vista.
● Por ejemplo: La salida más común para aplicaciones web es el
HTML. Podrían ser otras como un formulario, gráficos, etc.
Programación Orientada a Objetos– Sesión 8
Analogía del MVC
Programación Orientada a Objetos– Sesión 8
Flujo de control
1. El usuario realiza una acción en la interfaz.
2. El controlador trata el evento de entrada.
3. El controlador notifica al modelo la acción del usuario, lo que puede implicar un
cambio del estado del modelo (si no es una mera consulta).
4. Se genera una nueva vista. La vista toma los datos del modelo.
El modelo no tiene conocimiento directo de la vista
5. La interfaz de usuario espera otra interacción del usuario, que comenzará otro nuevo
ciclo.
Programación Orientada a Objetos– Sesión 8
Funcionamiento en la Web
En la web, el MVC funcionaría así.
Cuando el usuario manda una petición al navegador, digamos quiere ver un sitio
específico el controlador responde a la solicitud, porque él es el que controla la
lógica de la app, luego le pide al modelo la información del curso.
El modelo, que se encarga de los datos de la app, consulta la base de datos y
obtiene toda la información.
Luego, el modelo responde al controlador con los datos que pidió.
Finalmente, el controlador tiene los datos solicitados, se los manda a la vista,
pudiendo aplicar los estilos (Hojas de estilos CSS), organizar la información y
construir la página que se observa en el navegador.
Programación Orientada a Objetos– Sesión 8
Ventajas del MVC
Fácil organización del código en tres componentes diferentes.
Crea independencia del funcionamiento.
Facilita agregar nuevos tipos de datos según sea requerido por la aplicación ya que
son independientes del funcionamiento de otras capas.
Si trabaja con un equipo de programadores entonces les da una mayor facilidad para
poder seguir el trabajo entre varios integrantes.
Facilita el mantenimiento en caso de errores.
Hacen que las aplicaciones sean fácilmente extensibles.
Poder adaptarse a los frameworks de hoy en día.
Programación Orientada a Objetos– Sesión 8
Desventajas del MVC
La separación de conceptos en capas agrega complejidad al sistema.
La cantidad de archivos a mantener y desarrollar se incrementa considerablemente.
La curva de aprendizaje del patrón de diseño es más alta que usando otros modelos
sencillos.
Programación Orientada a Objetos– Sesión 8
EJEMPLOS DEL MVC
Programación Orientada a Objetos– Sesión 8
Ejemplo 1: Implementación del MVC en Java
Programación Orientada a Objetos– Sesión 8
Ejercicio
● Para aplicar el MVC a nuestro ejemplo tendremos que desarrollar una serie
de módulos independientes que se encarguen, en dos capas (acción y
estado) del acceso a los datos.
Programación Orientada a Objetos– Sesión 8 Paso 1:Modelo
Primero se crea el modelo, que es una clase en java y se llama Cliente.java, esta clase sólo contiene los
atributos, constructor, getters y setters.
Programación Orientada a Objetos– Sesión 8
Paso 1: Modelo
Se definen los campos ("fields") utilizados en un
contexto privado (private).
Se definen constructores Java, Constructor "default" sin
datos de entrada.
A través de los diversos métodos get/set es posible
modificar los valores iniciales definidos en el Java Bean.
Paso 2:Vista
Programación Orientada a Objetos– Sesión 8
Luego se crea la vista, la clase ClienteView.java, para el ejemplo y su función
es presentar los datos del modelo.
Programación Orientada a Objetos– Sesión 8
Paso 3: Controlador
● Ahora se crea el controlador que contiene 2 objetos: el modelo y la vista.
● Así como los getters y setters para llenar las propiedades del modelo y un
método(actualizarVista()) que llama a la vista que a su vez imprime las
propiedades del modelo cliente.
Programación Orientada a Objetos– Sesión 8
Paso 3: Controlador
Programación Orientada a Objetos– Sesión 8
Paso 3: Controlador
Se declara los objetos
Paso 3: Controlador
Programación Orientada a Objetos– Sesión 8
Presentación de
los datos
Programación Orientada a Objetos– Sesión 8
Paso 4: Test MVC
Programación Orientada a Objetos– Sesión 8
Resultado en consola
Ejemplo 2: Calculadora con Java Swing
Programación Orientada a Objetos– Sesión 8
● Una clase sencilla para sumar variables
Programación Orientada a Objetos– Sesión 8
Ejemplo 2: Calculadora con Java Swing
Crea un nuevo proyecto en netbeans, para este ejemplo, el proyecto se
llama “MVC".
Crea una estructura de paquetes (Controller, Model, View), hacemos esto para
separar cada componente y ser más organizados.
Programación Orientada a Objetos– Sesión 8
Pasos
1. Creación del proyecto
2. Creación del modelo
3. Codificación de la clase Vista
4. Codificación de la clase Controlador
5. Codificación de la clase Principal
6. Prueba del proyecto MVC
Programación Orientada a Objetos– Sesión 8
Paso 1: Creación del proyecto
Programación Orientada a Objetos– Sesión 8
Paso 1: Creación del proyecto
● Como puedes observar, mantenemos el paquete default junto al MVC.java
que nos crea netbeans, este main es el que nos servirá como nuestro index
de nuestra aplicación, nuestro "lanzador".
Programación Orientada a Objetos– Sesión 8
Paso 2: El modelo
Empecemos creando la lógica de la aplicación, crea una nueva clase en el
paquete Model, llámalo "modelo.java" y añade el siguiente código:
Programación Orientada a Objetos– Sesión 8 Paso 2: El modelo
valores
La suma de dos
Programación Orientada a Objetos– Sesión 8
Paso 3: La vista
Paso 3:La vista
Programación Orientada a Objetos– Sesión 8
Se añade un JFrame al paquete VIEW, llámalo “Vista.java”.
Programación Orientada a Objetos– Sesión 8
Paso 3:Vista
● En Java existe una biblioteca gráfica (Componentes
Swing) la cual incluye widgets para la interfaz gráfica
de usuario (cajas de texto, botones, menús entre
otros...).
● Para esta "MiniCalculadora« haremos uso
JTextField (campos de texto) para los operando y
uno para mostrar el resultado, un JButtons (botón)
para la operación , a su vez algunos JLabels para
mostrar ciertos textos en la ventana.
Programación Orientada a Objetos– Sesión 8
Paso 4: Controlador
Programación Orientada a Objetos– Sesión 8
Paso 5: Clase Principal
Programación Orientada a Objetos– Sesión 8
Paso 6: Prueba
Programación Orientada a Objetos– Sesión 8 Resultado
Programación Orientada a Objetos– Sesión 8
Breve explicación
Nuestra clase controlador, implementa el ActionListener, esto para responder
desde esta clase, los eventos realizados desde la interfaz (VISTA).
El constructor de la clase pasa como parámetros, la clase VISTA y la clase
MODELO.
Nuestra clase ademas cuenta las funciones, INICIAR() la cual inicializa los
valores de la interfaz, como ser el atributo titulo del JFrame, posicionamiento
en pantalla, valores iniciales de los jtextbox, etc.
El método action performed captura el evento realizado desde la interfaz.
Un CLICK EN EL BOTON SUMAR, obtiene los datos correspondientes e
invoca al modelo para procesar la información y obtener una respuesta.
Autoevaluación
Sesión 1
¿Qué se entiende por "bajo acoplamiento" en el contexto del diseño de
software?
Es la medida de la dependencia entre dos o más componentes del sistema.
Pregunta 1
Es la medida de la similitud entre los componentes del sistema.
Es la medida de la complejidad de un componente del sistema.
Es la medida de la capacidad de un componente para reutilizar código.
¿Qué se entiende por "alta cohesión" en el contexto del diseño de
software?
Es la medida de la dependencia entre dos o más componentes del sistema.
Pregunta 2
Es la medida de la similitud entre los componentes del sistema.
Es la medida de la complejidad de un componente del sistema.
Es la medida de la relación entre un componente y su entorno.
¿Qué principio de GRASP se refiere a la asignación de la responsabilidad de
manejar las solicitudes de entrada y coordinar las acciones de un sistema?
Bajo Acoplamiento
Pregunta 3
Alta Cohesión
Controlador
Experto en Información
¿Por qué es importante la alta cohesión en el diseño de software?
Porque reduce la modularidad del sistema.
Pregunta 4
Porque aumenta la complejidad del sistema.
Porque facilita la comprensión, el mantenimiento y la reutilización del código.
Porque aumenta la dependencia entre los componentes del sistema.
Autoevaluación
¡Vamos por más logros!
¡Felicitaciones!
Ha concluido la autoevaluación
Aplicar los principios de Bajo
Acoplamiento y Alta Cohesión, junto
Conclusiones
con el patrón Controlador, contribuye
a un diseño de software más modular,
mantenible y flexible. Estos
conceptos son esenciales para
desarrollar sistemas que puedan
adaptarse a los cambios en los
requisitos del negocio y en el entorno
tecnológico, y que puedan
evolucionar con el tiempo sin
comprometer la calidad y la
estabilidad del software.
Aplicando lo
aprendido:
GUIA DE LABORATORIO N°8
JOYANES, Luis: Programación En Java Algoritmos Programación
Orientadas A Objetos E Interfaz Gráfica De Usuario [en línea].
México: Mc Graw Hill, 2011. ISBN 9786071506184. Disponible en:
Referencias
https://
ucv.primo.exlibrisgroup.com/permalink/51UCV_INST/175ppoi/alma99
1001051429707001
