Download Aplicaciones Java - Departamento de Ingeniería de Sistemas

Programación Orientada a Objetos
Aplicaciones Java
Ing
Ing.. Julio Ernesto Carreño Vargas
MsC..
MsC
Aplicaciones Java
Ingeniería de Sofwatre
Patrones: MVC
Programación Orientada a Objetos
2
1
Ingeniería de Software
Es la aplicación de una aproximación sistemática
y disciplinada para el desarrollo, pruebas y
mantenimiento de un programa
Programación Orientada a Objetos
3
Ciclo de vida de software
Es la secuencia de estados de un programa desde
su concepción hasta su operación
Cubre cinco estados:
Análisis : ADOO
Diseño: ADOO
Codificación: POO
Pruebas: POO
Operación y mantenimiento
Programación Orientada a Objetos
4
2
Análisis y Diseño
Programación Orientada a Objetos
5
Testing
Evaluación que es ejecutada por máquinas ó
humanos para asegurar la calidad de los
programas
El objetivo del testing es encontrar errores en el
programa
Realizar el testing de los programas no garantiza
la ausencia de error en ellos.
Programación Orientada a Objetos
6
3
Testing con JUnit
Programación Orientada a Objetos
7
Testing con JUnit
Programación Orientada a Objetos
8
4
Testing con JUnit
Programación Orientada a Objetos
9
Debugging
Es el proceso de localizar y corregir errores
lógicos y errores en tiempo de ejecución en los
programas
La manera más simple es usar el método println
Java tiene un depurador basado en texto llamado
el jdb.
jdb.
Programación Orientada a Objetos
10
5
Debugging
Programación Orientada a Objetos
11
Refactoring
Un proceso de
refactorización o
Refactoring consiste en
modificar el código
fuente de un sistema
que ha sido diseñado y
codificado de manera
inexperta para lograr un
sistema más
estructurado y fiable
Programación Orientada a Objetos
12
6
Refactoring
Programación Orientada a Objetos
13
Refactoring
Programación Orientada a Objetos
14
7
Refactoring
Programación Orientada a Objetos
15
Refactoring
Programación Orientada a Objetos
16
8
Control de Versiones
Es importante guardar pista de las diferentes
versiones de desarrollo de un programa de
modo que pueda ser posible volver a una
versión anterior del programa
Entre los programas más usados se encuentran:
CVS (Concurrent Version System)
SubVersion
Programación Orientada a Objetos
17
Control de Versiones en
SubVersion
Programación Orientada a Objetos
18
9
Patrones
Un patrón es una solución a un problema
recurrente.
Los patrones de software describen un problema que
ocurre repetidas veces en algún contexto
determinado de desarrollo de software y entregan
una buena solución ya probada.
Los patrones capturan las mejores prácticas
establecidas para diseño.
Programación Orientada a Objetos
19
Beneficios Patrones
Facilita la documentación y comunicación con
otros miembros del equipo de desarrollo.
Reutilización
Mantenibilidad (disminuye errores)
Extensibilidad (adicionar nuevas características)
Reestructuración (reorganización de
componentes)
Portabilidad.
Programación Orientada a Objetos
20
10
GRASP
GRASP: General Responsabilities Assignment Software
Patterns (Patrones de Asignación de
Responsabilidades).
La asignación de responsabilidades es la habilidad en el
análisis y diseño orientado por objetos.
GRASP es la descripción de los principios fundamentales de
la asignación de responsabilidades expresados como patrones.
Los principios fundamentales GRASP son uno de los
factores críticos para obtener diseños reutilizables,
mantenibles, entendibles y extensibles.
Programación Orientada a Objetos
21
GRASP –Patrón Experto (Expert)
Cada objeto es responsable por mantener su propia
información, principio de encapsulamiento
Conoce y puede informar el valor de sus atributos
Puede modificar el valor de sus atributos
Cuando el objeto tiene relaciones de agregación
con otros objetos, también será responsable de
conocer la información de ellos, de crearlos
(patrón creador) y de delegarles las operaciones.
Programación Orientada a Objetos
22
11
GRASP –Patrón Creador (Creator)
Problema: Quién es el responsable de crear una nueva
instancia de una clase?
Solución: El objeto B tiene la responsabilidad de crear
objetos de la Clase A si:
B agrega objetos A
B contiene objetos A
B registra objetos A
B usa exhaustivamente objetos A
B posee la información necesaria para inicializar a A
Programación Orientada a Objetos
23
GRASP –Patrón Bajo Acoplamiento
(Low Coupling)
Acoplamiento es la medida de cuanto una clase está
conectada (tiene conocimiento) a otras clases.
Un bajo acoplamiento permite que el diseño de clases
sea más independiente.
Demasiado acoplamiento significa que los cambios a una
clase podrían tener también cambios inesperados en otras
Reduce el impacto de los cambios y aumenta la reutilización.
Puede no ser importante si la reutilización no es un
objetivo.
Programación Orientada a Objetos
24
12
GRASP –Patrón Bajo Acoplamiento
(Low Coupling)Object1
Object2
Object3
Object4
Object5
Message1()
Message2()
Message3()
Message4()
Message5()
Message6()
Message7()
Message8()
Low coupling (decentralized)
Each object sees two other objects at most
Programación Orientada a Objetos
25
GRASP –Patrón Bajo Acoplamiento
(Low Coupling)Object1
Object2
Object3
Object4
Object5
Message1()
Message8()
Message3()
Message6()
Message4()
Message5()
Message7()
Message2()
High coupling (centralized)
Object1 must see all other objects
Programación Orientada a Objetos
26
13
GRASP –Patrón Alta Cohesión (High
Cohesion)
Cohesión funcional dentro de una clase es una
medida que indica cuan relacionadas están las
responsabilidades de una clase.
En otras palabras, no haga que un objeto haga
demasiado trabajo.
Entre más alta cohesión más fácil de entender,
de cambiar, de reutilizar la clase.
Un objeto con una única simple función
compleja (hace todo) puede resultar en baja
cohesión.
Programación Orientada a Objetos
27
GRASP –Patrón Controlador
(Controller)
Un evento de entrada al sistema es algún evento
desde algún actor externo (humano ó no)
El objeto controlador es responsable de decidir
que hacer con el evento.
El controlador se aplica para el manejo de
interfaces externas y al manejo de entradas desde
interfaces de usuario.
Programación Orientada a Objetos
28
14
GRASP –Controlador de FachadaSystem
Object8
facade
externalSystem
Object7
Object6
Object9
Programación Orientada a Objetos
29
GRASP –Controlador de Fachada
El controlador actua como una fachada entre la
interface y la aplicación.
El controlador de fachada oculta todo un sistema
debajo de una clase.
Pueden existir varias fachadas, esto para evitar que
una sola clase controladora sea muy grande.
Programación Orientada a Objetos
30
15
GRASP –Controlador de Fachada
Las fachadas permiten mantener la separación
del modelo de negocios y la vista (Graphical
User Interface), la vista no debe interactuar
directamente con el modelo, esto se conoce
como el modelo vista controlador (MVC).
Permita mantener bajo acoplamiento.
Programación Orientada a Objetos
31
Model View Controller
Un patrón usado para ayudar a separar la capa de
interface de las otras partes del sistema.
Controller
Obtener en trada
Programación Orientada a Objetos
Model
View
Almace nar datos
Mostrar datos
32
16
Model View Controller
Modelo. El modelo administra el comportamiento y
los datos del dominio de aplicación, responde a
requerimientos de información sobre su estado
(usualmente formulados desde la vista) y responde a
instrucciones de cambiar el estado (habitualmente
desde el controlador).
Vista. Maneja la visualización de la información.
Controlador. Interpreta las acciones del ratón y el
teclado, informando al modelo y/o a la vista para
que cambien según resulte apropiado.
Programación Orientada a Objetos
33
MVC
Tanto la vista como el controlador dependen del
modelo, el cual no depende de las otras clases. Esta
separación permite construir y probar el modelo
independientemente de la representación visual.
Usos:
Sistemas interactivos,
sistemas con múltiples GUI.
view
controller
Programación Orientada a Objetos
34
17
Ventajas MVC
Reutilización
Soporte de vistas múltiples y Adaptación al cambio
Programación Orientada a Objetos
35
Desventajas de MVC
Complejidad.
Costo de actualizaciones frecuentes.
Desacoplar el modelo de la vista no significa que los
desarrolladores del modelo puedan ignorar la naturaleza de
las vistas.
Programación Orientada a Objetos
36
18
Implementar MVC en Java
Se crea un package por
cada una de los
componentes MVC
Cada paquete contiene
las clases necesarias para
cumplir con la
responsabilidad de dicha
capa.
Programación Orientada a Objetos
37
Patrón Fachada en las Capas
Use el patrón fachada en cada una de las capas
las otras capas solicitarán servicios a la fachada, y
esta delegará el trabajo a las clases internas.
Las fachadas podrían ser marcadas como clases
<<interface>>.
Programación Orientada a Objetos
38
19
Intercambio de datos entre capas(1)
La información que fluye entre las capas debería estar
basada en objetos
Si son varios objetos debe usarse una colección de objetos
El usuario introduce la información desde el GUI
Arraylist, hashtable
dicha información es mantenida en los objetos de negocio.
Los objetos java son manipulados en la capa de negocio
y/ó enviados a la capa de presentación para que sean
desplegados al usuario
Programación Orientada a Objetos
39
Bibliografía
Paul Deitel.
Deitel. Como programar en Java 7/e. Pearson Education
Education..
2007.
C. Thomas Wu.
Wu. An Introduction to Object Oriented
Programming with Java
Programación Orientada a Objetos
40
20