Responsibility-Driven Design RDD

Jos Sulla Torres

Introduccin

UML es slo un lenguaje de modelado visual. UML no ensea cmo pensar en objetos.
La herramienta de diseo crtico para el desarrollo de software es una mente bien educada en los principios de diseo.

Repaso de artefactos de anlisis

Modelo de Dominio
Sale date ... quantity 1 1 ..

Sales
LineItem ...

...

Process Sale
Process Sale

Modelo de Casos de Uso Texto Use Case

.

Cashier

1 . Customer nombres Caso de usoo arrives ... 2 . ... 3 . Cashier enters item

identifier

Diagrama Caso de Uso

ideas for the post conditions : System -

system events

Operation
enterItem

:
( )

: Cashier

make

Post - ...

- conditions

system operations

NewSale enterItem ( id , quantity

()

Sistema de diagramas de secuencia

Contratos de Operacin

Actividades de diseo de objetos

Los artefactos creados durante el anlisis se convierten en entradas para el diseo de objetos

Texto de caso de uso

Durante el diseo OO, la comprensin de casos de uso estn diseados para llevar a cabo los casos de uso. Esto define los objetivos no funcionales que deben ser satisfechos por los objetos.

Especificacin complementaria

Sistema de diagramas de secuencia

Los mensajes de operacin del sistema en los diagramas de secuencia se convierten en los mensajes de inicio en los diagramas de interaccin.

Glosario

El glosario aclara los detalles de los parmetros o datos que vienen de la capa de interfaz de usuario, los datos que se pasan a la base de datos y la validacin de los requisitos.

Contratos de operaciones

Los contratos de operacin pueden complementar el texto de caso de uso para aclarar qu es lo que los objetos de software deben lograr en una operacin del sistema.
El modelo de dominio sugiere algunos nombres y atributos de los objetos de dominio de software en la capa de dominio de la arquitectura de software

Modelo de Dominio

El enfoque general para hacer el modelado de diseo orientado a objetos se basa en la metfora del diseo dirigido por responsabilidad (RDD).

En RDD, pensamos acerca de cmo asignar responsabilidades a los objetos que colaboran.

Durante el diseo OO, diversos principios de diseo orientados a objetos se aplican a travs de patrones de diseo como el GRASP y el Four Gang-of-(GoF).

Salidas del Diseo de Objetos

El resultado del proceso de diseo no es un producto final:

Las decisiones de diseo pueden ser revisadas, incluso despus de la implementacin El diseo no es lineal sino iterativo

El proceso de diseo no es algortmica:

Un mtodo de diseo proporciona las guas, no reglas fijas . "Un buen sentido del estilo a menudo ayuda a producir claros y elegantes diseos los diseos que se hacen dan mucho sentido desde el punto de vista de la ingeniera"
Responsibility-driven design es una tcnica de (anlisis y) diseo que funciona bien en combinacin con varios metodos y notaciones.

Salidas del Diseo de Objetos

Las principales salidas del diseo de objetos son los diagramas de interaccin y de clase. Otras salidas:

Diagrama de Paquetes Bocetos y prototipos de interfaz de usuario Modelo de Base de datos Bocetos y prototipos de reportes

Responsabilidades
Qu son responsabilidades?

el conocimiento de un objeto que mantiene y proporciona las acciones que puede realizar

Las responsabilidades representan los servicios pblicos de un objeto puede proporcionar a los clientes (pero no de la forma en que estos servicios pueden ser implementados)

Especifica lo que hace un objeto, no cmo lo hace No describe la interfaz todava, slo las responsabilidades conceptuales

Responsabilidades y diseo dirigido por responsabilidad

Una forma de pensar en el diseo de objetos de software es en trminos de responsabilidades, roles y colaboraciones. En RDD, pensamos en objetos de software que tienen responsabilidades. Las responsabilidades de un objeto se refiere a sus obligaciones o el comportamiento en trminos de su rol. Las responsabilidades se asignan a clases de objetos durante el diseo del objeto.

Basicamente, un objeto tiene dos tipos de responsabilidades:

Responsabilidad Hacer (Doing) como:

Hacer algo en s, como la creacin de un objeto o hacer un clculo. Iniciar una accin en otros objetos. Controlar y coordinar actividades en otros objetos. Conocer sobre los datos privados encapsulado. Conocer sobre los objetos relacionados. Conocer sobre de las cosas que puede derivar o calcular.

Responsabilidad Conocer (Knowing) como:

Ejemplos:

responsabilidad responsabilidad de una venta responsabilidad venta responsabilidad

de calcular el total de una venta de conocer la linea de elementos de generar un recibo de una de manejar una nueva venta

Gua: El modelo de dominio a menudo inspira "conocer" las responsabilidades de los objetos de dominio de software.

Por ejemplo, supongamos que la clase Venta tiene un atributo tiempo en el modelo de dominio. Podramos entonces asignar a la clase de software de Venta la responsabilidad de conocer el tiempo de la venta.

Las responsabilidades y los mtodos no son los mismos. Mtodos realizan las responsabilidades. La traduccin de responsabilidades en clases y mtodos se ve influida por la granularidad de la responsabilidad.

Grandes responsabilidades pueden traducirse en cientos de clases y mtodos.

Ejemplo: responsabilidad de proveer el acceso a bases de datos relacionales

Pequeas responsabilidades podran tomar slo un mtodo.

Ejemplo: responsabilidad de crear un Venta

RDD tambin incluye la idea de colaboracin. Las responsabilidades son implementados por medio de mtodos que actan ya sea solo o colaboran con otros mtodos y objetos. RDD es una metfora general para pensar en el diseo de software orientado a objetos. Esto lleva a la visualizacin de un diseo orientado a objetos como una comunidad de colaboracin objetos responsables.

Exploracin Inicial
1.

Encontrar las clases en tu sistema

Determina las responsibilidades de cada clase

2.

3.

Determina como los objetos colaboran con cada otro para realizar sus responsabilidades

Identificando las responsabilidades

Estudio de la especificacin de requerimientos:

resaltar los verbos y determinar cuales representan las responsabilidades realizar un revisin por el sistema

explorar tantos escenarios como sea posible identificar las acciones resultantes de entrada al sistema

Estudiar a las clases candidatas:

Nombre de clase roles responsabilidades Registrar los propsitos en las tarjeta de clases responsabilidades

Tarjetas CRC (Candidates, Responsibilities, and Collaborators)

Uso de tarjetas CRC para registrar clases candidatas:
Nombre de candidata Superclase Subclase Lista de potenciales responsabilidades Lista de objetos colaboradores

- Qu conoce
- Qu hace

- Qu decisin Registra la clase candidata Nombre de la Clase y la superclase (si hubiera) Registra cada Responsabilidad y las clases Colaborativas compacto, fcil para manipular, fcil para modificar o descartar Fcil para arreglar, reorganizar Fcil para recuperar clases discartadas

Tarjetas CRC

Ejercicio