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.