Post on 01-Jul-2015
REPÚBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DE EDUCACIÓN SUPERIOR
I.U.P “SANTIAGO MARIÑO”
CÁTEDRA: SISTEMAS II
Metodología RDD (Responsabilidad Driven Design)
Profesor: Integrantes:
Guillermo Oropeza Ronald Rangel C.I: 15.040.761
Adriana García C.I: 17.100.061
Francy Delgado C.I: 14.872.365
José García C.I: 17.470.208
John Rondón C.I: 14.035.055
Caracas, Enero 2011
INTRODUCCIÓN
En el ámbito empresarial de la programación y el desarrollo de software
resulta vital la definición temprana, de forma clara y completa, de las
necesidades del usuario (cliente) para la definición de la calidad del software
a elaborar, de tal forma que el proceso de desarrollo apunte a la satisfacción
de las mismas y que el producto logrado corresponda a lo planificado.
Por otra parte, el desarrollo de software abarca un proceso, que al igual que
toda actividad humana, está expuesta a la ocurrencia de errores y la
inclusión de cambios lo que la hace dinámica y no rígida ni del todo
predecible o controlable.
El ciclo de vida del desarrollo Orientado a Objeto (O-O) consiste en el
desarrollo progresivo de la representación de objetos a través de tres fases
análisis, diseño e implementación, similares a las del ciclo de vida de
desarrollo simplificado.
Una vez desarrollado el proceso de programación O-O se desenvuelven
distintas metodologías entre la que destaca la Driven Design
Responsabilidad Conocido como Responsabilidad Driven Design, es una
manera de diseñar sistemas complejos de software utilizando objetos y la
tecnología de componentes.
Implica describiendo las acciones y actividades para las que nuestro
software es responsable describir las responsabilidades en cuanto a que
tanto los usuarios y desarrolladores pueden entender el diseño de objetos
de software que implementan las responsabilidades
Paradigma de da Orientación a Objeto
Es una “nueva” manera de ver y expresar el mundo, de pensar acerca de los
problemas para encontrar una representación adecuada a nivel de software.
El software es organizado como una colección de unidades atómicas (los
OBJETOS) constituidas por datos y funciones, que interactúan entre sí.
Desarrollo de Software O-O (Orientada Objeto)
Los CONCEPTOS inherentes al dominio de la aplicación son
identificados, organizados y comprendidos antes de que los detalles
sobre las estructuras de datos y las funciones puedan ser
considerados efectivamente.
Es un proceso conceptual INDEPENDIENTE del lenguaje de
programación hasta que se encuentra en sus etapas finales.
Consiste en la construcción y paulatino refinamiento del MODELO
DEL DOMINIO DE LA APLICACIÓN para, finalmente, agregarle los
detalles de implementación.
Potenciales Beneficios de la Tecnología O-O
Promueve la reusabilidad.
Reduce la complejidad del mantenimiento (extensibilidad y facilidad de
cambios).
Riqueza semántica.
Disminuye la brecha semántica entre la visión interna y la visión
externa del sistema.
Facilita la construcción de prototipos.
Algunos Métodos O-O (Orientada Objeto)
Diseño Basado en Responsabilidades (Wirfs-Brock et al., 1990)
Análisis Orientado a Objeto (Peter Coad y Ed. Yourdon, 1991)
Diseño Orientado a Objeto (Peter Coad y Ed. Yourdon, 1991)
Diseño Orientado a Objeto (Grady Booch, 1991)
Técnica de Modelación Orientada a Objeto: OMT (James Rumbaugh
et al., 1991)
Ingeniería de Software Orientada a Objeto: OOSE (Ivar Jacobson et
al., 1992)
Fusión (Derek Coleman et al., 1994)
Lenguaje de Modelación Unificado: UML (Rational Corporation, 1996)
Ciclo De Vida de Desarrollo O-O (Orientada Objeto)
El ciclo de vida de desarrollo O-O consiste en el desarrollo progresivo de la
representación de objetos a través de tres fases análisis, diseño e
implementación, similares a las del ciclo de vida de desarrollo simplificado.
En contraste con del ciclo de vida tradicional, gráficamente se asemeja más
a una “cebolla” (por capas) que a una cascada.
El Proceso de Análisis y Diseño O-O (Orientado Objeto)
En la fase de análisis, el modelo del mundo real de la aplicación es
desarrollado mostrando sus propiedades importantes. Los conceptos
abstractos de la aplicación dominan y describen QUÉ debe hacer el
sistema, más que CÓMO lo va a hacer.
El modelo de análisis especifica el comportamiento funcional del
sistema, independientemente de los aspectos relativos al ambiente en
el que va a ser finalmente implementado.
Es necesario tomar el tiempo suficiente para entender claramente los
requerimientos del problema.
El modelo de análisis captura completamente y con exactitud los
requerimientos del sistema.
Siempre hay que tener presente que es más fácil y menos costoso
hacer cambios o arreglar defectos en el análisis que en las fases
siguientes.
En la fase de diseño O-O, se define cómo el modelo de análisis
orientado a la aplicación va a ser realizado en el ambiente de
implementación.
Ventajas de la Programación Orientación a Objetos
Reutilización
El diseñador piensa en términos del comportamiento de objetos y no
en detalles de bajo nivel.
Confiabilidad
Un diseño más rápido
Integridad
Mantenimiento más sencillo. Modificaciones locales.
Ciclo vital dinámico.
Modelado más realista.
Modelos empresariales inteligentes.
Independencia del diseño.
Computación Cliente-Servidor.
Computación paralela.
Eficacia de la máquina.
Mejores herramientas CASE.
Bibliotecas de clases para las empresas.
Estabilidad
Se construyen clases cada vez más complejas.
Nuevos mercados para el software.
Diseño de mayor calidad.
Programación más sencilla.
Invención.
Esmero durante la construcción
Mejor comunicación entre los profesionales de los Sistemas de
Información y los empresarios.
Especificaciones declarativas y diseño.
Interacción.
Computación de distribución masiva.
Mayor nivel de automatización de las bases de datos.
Migración.
Bibliotecas de clases para las industrias.
La comprensión del sistema es más fácil porque la semántica entre el
sistema y la realidad son similares.
Driven Design Responsabilidad
Conocido como Responsabilidad Driven Design, es una manera de diseñar
sistemas complejos de software utilizando objetos y la tecnología de
componentes. Guiados por la responsabilidad del diseño fue concebido en
1990 como un cambio de pensamiento sobre los objetos como datos más
algoritmos, a pensar en objetos como papeles más responsabilidades.
Guiados por la responsabilidad cataliza la tecnología de diseño de objetos
con técnicas prácticas y herramientas de pensamiento. Responsabilidad-
Driven Design tiene sus raíces en el diseño de Smalltalk y el desarrollo, en el
que todo es un objeto y la manera de estructurar una aplicación es la
concepción de empresas que cooperaron objetos a la derecha. Dado que
estas tecnologías objeto primeros días, basada en la responsabilidad del
diseño ha tenido una profunda influencia en otras impulsado el desarrollo de
"prácticas".
En un modelo basado en la responsabilidad, los objetos desempeñan
funciones específicas y ocupan posiciones bien conocidas en la arquitectura
de la aplicación. Se trata de una comunidad sin problemas de ejecución de
los objetos. Cada objeto es responsable de una parte específica de la obra.
Objetos de colaborar en formas claramente definidas, la contratación entre sí
para cumplir los objetivos más amplios de la aplicación. Al crear una
"comunidad de objetos," la asignación de responsabilidades específicas a
cada uno, a construir un modelo de colaboración de su aplicación.
Los objetos son más que paquetes simples de la lógica y los datos que son
los proveedores de servicios, los titulares de la información, estructuradores,
los coordinadores, los controladores, e interfaces con el mundo exterior.
Cada uno debe saber y hacer su parte. Pensar en términos de estos
estereotipos objeto función le permite construir, flexibles aplicaciones de gran
alcance. El desarrollo de estilos de control coherente de las piezas similares
de su aplicación reduce costos de mantenimiento.
Responsabilidad Driven Design (RDD) implica describiendo las acciones y
actividades para las que nuestro software es responsable describir las
responsabilidades en cuanto a que tanto los usuarios y desarrolladores
pueden entender el diseño de objetos de software que implementan las
responsabilidades.
La responsabilidad del diseño impulsado:
Responsibility-driven design is a design technique in .Impulsada por el
diseño de Responsabilidad es una técnica de diseño en la programación
orientada a objetos . It was proposed by and Brian Wilkerson who defined it
as follows: Fue propuesto por Rebecca Wirfs-Brock Wilkerson y Brian, que se
define de la siguiente manera:Responsibility-driven design is inspired by the
client/server model. La responsabilidad del diseño orientado se inspira en el
modelo cliente / servidor. It focuses on the contract by asking:
Se centra en el contrato, preguntando:
What actions is this object responsible for? ¿Qué acciones es
responsable de este objeto?
What information does this object share? ¿Qué información esta acción-
objeto?
The model they refer to assumes that a software client and a software
server exchange information based on a contract that both parties
commit to adhere to.El cliente / servidor modelo que se refieren se supone
que un cliente de software y un servidor de software de intercambio de
información basado en un contrato que ambas partes se comprometen a
cumplir. The client may only make the requests specified, the server must
answer them. El cliente sólo puede hacer que las solicitudes se especifica, el
servidor debe responder. Thus, responsibility-driven design tries to avoid
dealing with details, such as the way in which requests are carried out, by
instead only specifying the intent of a certain request. Así, el diseño guiados
por la responsabilidad trata de evitar el trato con los detalles, tales como la
forma en la que se solicita se lleven a cabo, por única vez especificando el
propósito de una solicitud determinada. The benefit is increased
encapsulation, since the specification of the exact way in which a request is
carried out is private to the server. El beneficio se aumenta la encapsulación,
ya que la especificación de la forma exacta en que se lleva a cabo una
solicitud es privada en el servidor.
Diseño guiados por la responsabilidad
Una forma de diseño de software en la cual destaca una modelización del
comportamiento de las funciones de objetos, responsabilidades y
colaboraciones utiliza herramientas y técnicas de informales mejora los
procesos de desarrollo de XP (eXtreme Programming) a RUP (Rational
Unified Process) con los conceptos de responsabilidad y el pensamiento.
Impulsado por la Responsabilidad de los Recursos de Diseño Diseño
Orientado a Objetos Software por Wirfs Rebecca-Brock, Wilkerson y Brian
Wiener Lauren, Prentice-Hall, 1990 Nuestro nuevo libro tiene más técnicas y
prácticas. Diseño de objetos: funciones, Responsabilidades y
Colaboraciones, Rebecca Wirfs-Brock y Alan McKean, Addison-Wesley,
2003.
Diseño guiados por la responsabilidad Construye
Una aplicación = un conjunto de objetos que interactúan.
Un objeto = una puesta en práctica de una o más funciones.
Un papel = un conjunto de responsabilidades relacionadas.
Una responsabilidad = obligación de realizar una tarea o saber
información.
Una colaboración = una interacción de los objetos o las funciones (o
ambos).
Un contrato = un acuerdo que establece los términos de un
colaboración
Patrones GRASP
Un proceso de desarrollo sirve para normalizar quien hace que cosa en cada
momento y como debe realizarse esta cosa. En el mundo de las nuevas
tecnologías todo avanza rápido, por lo que es probable que todavía no
hayamos alcanzado un grado de madurez lo suficientemente elevado como
para poder normalizar actividades, fundamentalmente porque éstas cambian
de semana en semana.
Normalizando un proceso de desarrollo de software, lo que queremos ganar
(porque cuando hacemos algo normalmente es por ganar algo) pueden ser
distintas cosas:
Capacidad de predecir el coste futuro de la ejecución del siguiente
proyecto
Evitar riesgos con tareas no planificadas.
Eliminar dependencias a personas por producir piezas de un modo
estandarizado y documentado.
Aumentar la confianza en los sistemas desarrollados y reducir sus
errores.
Favorecer la reutilización de piezas (con la consiguiente reducción de
costes)
Existe una obra de proceso, llamado UML y Patrones, de Craig Larman, que
nos puede ayudar en la primera fase del diseño, la identificación de las
clases en base a su responsabilidad. Para comprender bien la obra anterior y
que los diseños sean completos, hacen falta consultar otras obras sobre
patrones de diseño (Coad, GoF, etc).
Un patrón es una descripción de un problema bien conocido que suele
incluir:
Descripción.
Escenario de Uso.
Solución concreta.
Las consecuencias de utilizar este patrón.
Ejemplos de implementación.
Lista de patrones relacionados.
GRASP es el acrónimo de General Responsibility Assignment Software
Patterns, que traducido es patrones general de responsabilidad de
asignación de software.
Una de las cosas más complicadas en orientación a objetos consiste en
elegir las clases adecuadas y decidir como éstas clases deben interactuar.
Incluso cuando se utilizan metodologías rápidas como programación extrema
(extreme programming) y se centra el proceso en el desarrollo continuo, es
inevitable elegir cuidadosamente las responsabilidades de cada clase en la
primera codificación y, fundamentalmente, en la refactorización (continual)
del programa. En su obra, Larman intenta definir un enfoque sistemático a la
creación de clases y métodos.
Los patrones de GRASP, no compiten con los patrones de diseño; sino que
ayudan para encontrar los patrones de diseño, los cuales son:
1) Bajo Acoplamiento:
Debe haber pocas dependencias entre las clases.
Para determinar el nivel de acoplamiento de clases, son útiles los
diagramas de colaboración de UML.
Uno de los principales síntomas de un mal diseño y alto acoplamiento
es una herencia muy profunda. Siempre hay que considerar las
ventajas de la delegación respecto de la herencia.
Como ejemplo (de mal diseño), en muchos diseños Web se puede ver
como se crea un servlet base con capacidades de paginación y se
hereda de él para construir los demás. La paginación es un servicio
que se podría usar en aplicaciones no Web, por lo que es más
adecuado mantener estas capacidades en clases externas.
2) Alta Cohesión:
Cada elemento de nuestro diseño debe realizar una labor única dentro
del sistema, no desempeñada por el resto de los elementos y auto-
identificable.
Ejemplos de una baja cohesión son clases que hacen demasiadas
cosas.
En todas las metodologías se considera la refactorización. Uno de los
elemento a refactorizar son las clases saturadas de métodos.
Ejemplos de buen diseño se producen cuando se crean los
denominados "paquetes de servicio" o clases agrupadas por
funcionalidades que son fácilmente reutilizables (bien por uso directo o
por herencia).
3) Experto:
La responsabilidad de realizar una labor es de la clase que tiene o
puede tener los datos involucrados (atributos). Una clase, contiene
toda la información necesaria para realizar la labor que tiene
encomendada.
Hay que tener en cuenta que esto es aplicable mientras se estén
considerando los mismos aspectos del sistema:
Lógica de negocio
Persistencia a la base de datos
Interfaz de usuario
No tiene sentido considerar que una clase se debe escribir a sí misma
en base de datos o formatearse para presentarse en una página
HTML por el hecho de poseer los datos. Estos son elementos
estructuralmente distintos y deben considerarse desde una
perspectiva distinta.
4) Creador:
Se asigna la responsabilidad de que una clase B cree un Objeto de la clase A
solamente cuando
1. B contiene a A.
2. B es una agregación (o composición) de A.
3. B almacena a A.
4. B tiene los datos de inicialización de A (datos que requiere su
constructor).
5. B usa a A.
El hecho de crear objetos tiene casuísticas particulares:
Pool de Objetos
Caches
Instancias únicas
Estos casos son candidatos para la utilización de otros patrones más
concretos (de diseño).
A la hora de crear objetos en distintos lenguajes hay que tener en cuenta sus
peculiaridades. En Java por ejemplo:
No confundir referencias y el valor referenciado a la hora de retornar
objetos desde métodos.
Conocer la peculiaridad de las String (cadenas constantes).
Identificar problemáticas del recolector de basura y el uso de recursos
del sistema.
Conocer el ámbito y naturaleza de distintos tipos de componentes.
5) Controlador:
Asignar la responsabilidad de controlar el flujo de eventos del sistema,
a clases específicas. Esto facilita la centralización de actividades
(validaciones, seguridad, etc.). El controlador no realiza estas
actividades, las delega en otras clases con las que mantiene un
modelo de alta cohesión.
Un error muy común es asignarle demasiada responsabilidad y alto
nivel de acoplamiento con el resto de los componentes del sistema.
En UP (proceso unificado), al construir el modelo de análisis, existen
estereotipos predefinidos que favorecen la separación de entidades,
mecanismos de interfaz y mecanismos de control.
En aplicaciones Web, se tiende a separación de la lógica de
presentación y de la lógica de negocio. Patrones bien conocidos como
MVC o Fachada, son de amplia utilización.
En el diseño de clases de negocio, cuando no se tiene claro a qué
clase pertenece la responsabilidad de realizar una determinada tarea,
crear una clase controlador que se llame igual a la tarea a
desempeñar.
6) Polimorfismo:
Cuando se identifican variaciones en un comportamiento, asignar la
clase (interfaz) al comportamiento y utilizar polimorfismo para
implementar los comportamientos alternativos.
El implementar comportamientos alternativos con sentencias IF-ELSE,
no hace más que limitar la reutilización y crecimiento de la aplicación.
Por ejemplo, una aplicación muestra mensajes distintos en distintos
idiomas, con IF, al aumentar en uno el número de idiomas, obligaría a
añadir un nuevo IF. Con polimorfismo, sólo se debe crear un objeto de
una clase polimórfica nueva (bajo acoplamiento, alta cohesión y
potencial reutilización).
7) Fabricación Pura:
Cuando los problemas se complican, construir clases que se encarguen de
construir los objetos adecuados en cada momento (factorías).
Todo proyecto tiene numerosa factorías potenciales, para intercambiar
fácilmente comportamientos:
Look&Feel (decoradores y familias de componentes gráficos).
Sistemas de log.
Clases de acceso a gestor a bases de datos.
Sistemas multi-lenguaje.
Privilegios en base al rol de usuario.
Muchas más capacidades comunes.
8) Indirección:
Crear clases intermedias para desacoplar clientes de servicio y
servicios.
Pensar en sistemas middleware y se verá la utilidad de un modo
inmediato.
9) No hablar con extraños:
Un método, solamente invocará a métodos de:
De sí mismo (this).
De su área de parámetros.
Un objeto creado en su propio ámbito.
Un fallo común en la construcción de sistemas Web en la utilización de
variables globales (estáticas) o el acceso desde muchos puntos
desordenadamente a variables de sesión o aplicación (contexto).
Aunque pueden parecer muy evidentes los principios anteriormente
enumerados, es muy complicado llevarlo a cabo en proyectos reales. Hay
varios factores que lo hacen difícil.
Desventajas:
La presión del día a día por producir resultados (aunque sean de poca
calidad).
La planificación de proyectos a coste fijo (y a precios bajos) que no
incentiva el trabajo intelectual (más con 50 horas semanales de
trabajo).
La poca inversión en formación de muchas empresas (modelo de
servicios puro, propiciado los últimos años).
Falta de personas de referencia (que nos enseñen y aprendamos
juntos) en los equipos de desarrollo.
Tarjetas CRC
A fines de la década de 1980, uno de los centros más grandes de tecnología
de objetos era el laboratorio de investigación de Tektronix, en Portland,
Oregon, Estados Unidos. Este laboratorio tenía algunos de los principales
usuarios de Smalltalk y muchas de las ideas clave de la tecnología de
objetos se desarrollaron allí. Dos de sus programadores renombrados de
Smalltalk eran Ward Cunningham y Kent Beck.
Tanto Cunningham como Beck estaban y siguen preocupados por cómo
enseñar los profundos conocimientos de Smalltalk que habían logrado. De
esta pregunta sobre cómo enseñar objetos surgió la sencilla técnica de las
tarjetas de Clase-Responsabilidad-Colaboración (CRC).
En lugar de utilizar diagramas para desarrollar modelos, como lo hacían la
mayoría de los metodólogos, Cunningham y Beck representaron las clases
en tarjetas 4 x 6 [pulgadas]. Y en lugar de indicar atributos y métodos en las
tarjetas, escribieron responsabilidades.
El uso de las tarjetas C.R.C (Class, Responsabilities and Collaboration)
permiten al programador centrarse y apreciar el desarrollo orientado a
objetos olvidándose de los malos hábitos de la programación procedural
clásica.
Una responsabilidad en realidad es una descripción de alto nivel del
propósito de una clase. La idea es tratar de eliminar la descripción de
pedazos de datos y procesos y, en cambio, captar el propósito de la clase en
unas cuantas frases. El que se haya seleccionado una tarjeta es deliberado.
No se permite escribir más de lo que cabe en una tarjeta.
La segunda C se refiere a los colaboradores. Con cada responsabilidad se
indica cuáles son las otras clases con las que se tiene que trabajar para
cumplida. Esto da cierta idea sobre los vínculos entre las clases, siempre a
alto nivel.
Uno de los principales beneficios de las tarjetas de CRC es que alientan la
disertación animada entre los desarrolladores. Son especialmente eficaces
cuando se está en medio de un caso de uso para ver cómo lo van a
implementar las clases.
Los desarrolladores escogen tarjetas a medida que cada clase colabora en el
caso de uso. Conforme se van formando ideas sobre las responsabilidades,
se pueden escribir en las tarjetas. Es importante pensar en las
responsabilidades, ya que evita pensar en las clases como simples
depositarias de datos, y ayuda a que el equipo se centre en comprender el
comportamiento de alto nivel de cada clase.
Se pueden emplear diagramas de clase y de interacciones para captar y
formalizar los resultados del modelado CRC en un diseño con notación de
UML. Se debe asegurar que cada clase en el diagrama de clase tiene un
enunciado de sus responsabilidades.
CONCLUSIÓN
El énfasis metodológico se detecta desde los inicios del movimiento
sistémico, pero quizás por falta de claridad de los conceptos y la supuesta
mayor facilidad de comprensión y aplicación, las actividades académicas y
profesionales enfocadas al desarrollo, aplicación y difusión de sistemas han
dado diferentes énfasis, por lo que la metodología RDD ayuda a fortalecer la
programación Orientada a Objeto y resolver problemas puntuales y de forma
eficiente.
En un modelo basado en la responsabilidad, los objetos desempeñan
funciones específicas y ocupan posiciones bien conocidas en la arquitectura
de la aplicación. Se trata de una comunidad sin problemas de ejecución de
los objetos. Cada objeto es responsable de una parte específica de la obra.
Objetos de colaborar en formas claramente definidas, la contratación entre sí
para cumplir los objetivos más amplios de la aplicación. Al crear una
"comunidad de objetos," la asignación de responsabilidades específicas a
cada uno, a construir un modelo de colaboración de su aplicación
Un proceso de desarrollo sirve para normalizar quien hace que cosa en cada
momento y como debe realizarse esta cosa. En el mundo de las nuevas
tecnologías todo avanza rápido, por lo que es probable que todavía no
hayamos alcanzado un grado de madurez lo suficientemente elevado como
para poder normalizar actividades, fundamentalmente porque éstas cambian
de semana en semana.