viernes, 6 de noviembre de 2009

Técnicas de Analisis y Diseño Orientado a Objetos

TECNICAS DE ADOO

Para crear un sistema orientado a objetos es necesario analizar y diseñar orientado a objetos, UML no es suficiente, necesitamos usar técnicas adicionales para ayudarnos.

Algunas de estas técnicas que podemos usar para detectar Clases, Secuencias y otros son:
Narrativa de Casos de Uso – Técnica para describir la serie de pasos para llevar a cabo una funcionalidad en el sistema. No se tocará en este artículo.
Análisis CRC – Técnica para descubrir los objetos de negocio, mas tarde en la etapa de diseño se convierten en clases.
Análisis de Robustez o Modelo de Analisis – Técnica para encontrar la secuencia de llamadas entre los objetos involucrados en la solución de 1 caso de uso.
Diagrama de Capas y Niveles – Técnica que le ayuda al arquitecto a identificar la tecnología requerida en un sistema multicapa. Por la extensión del tema lo abordare en el siguiente artículo.


ANALISIS CLASE-RESPONSABILIDAD-COLABORACION (CRC)

Te has preguntado: ¿Cómo obtengo las clases de negocio del sistema?

Las clases core o de negocio pueden y deben obtenerse desde la fase de analisis, no se descubren hasta la construcción, para ello puedes aplicar la experiencia o usar esta técnica mientras te vuelves experto. No es la única técnica pero es muy efectiva.

El producto es un diagrama de clases de negocio llamado Modelo de Dominio. No contiene detalles técnicos como getters o atributos estáticos, más bien tipos básicos, asociaciones, cardinalidad y navegación.

Pasos para aplicar esta técnica:

Identificar Abstracciones Clave (Objetos de negocio candidatos)
1. Subrayar sustantivos en los documentos fuente de requerimientos: de Casos de Uso, Reportes, Requerimientos del SRS, minutas, etc.
2. Colocar los sustantivos en la lista de Abstracciones Clave candidatas

Identificar Responsabilidades: Atributos y Operaciones
3. Crear una tarjeta CRC por cada abstracción
4. Identificar propiedades de cada abstracción candidata
· Identificar atributos simples y compuestos
· Anotarlos en la sección de responsabilidades
5. Identificar operaciones de cada abstracción candidata.
· Identificar acciones, verbos que se aplican sobre la abstracción
· Anotarlos en la sección de responsabilidades

Identificar Colaboraciones
6. Identificar si la abstracción mantiene una relación “tiene un” “depende de” “contiene a” con otra
· Anotarla en la sección de colaboración
· Si hay una propiedad compuesta crear otra tarjeta, sacarla de la lista de propiedades y anotar su colaboración en ambas tarjetas

Eliminar abstracciones no clave
8. De la lista de candidatos eliminar las abstracciones clave que no colaboran o no forman parte como propiedad con otra abstracción.
· Colocar razones de eliminación.

Documentar el resultado del análisis
9. Crear diagrama de Objetos de Negocio (Modelo de Dominio)
· Anotar el nombre del Objeto, Cardinalidad, Navegación
· Introducir objetos intermedios para relaciones muchos a muchos




ANALISIS DE ROBUSTEZ

Ok ya tengo los objetos y ahora ¿Como entran en acción en cada caso de uso?
El sistema no se forma solo de clases de negocio, ¿Como obtener las demas clases que intervienen en el sistema?

Esta técnica no es muy conocida pero es muy útil, responde las preguntas anteriores y además ayuda a separar los elementos del sistema por capas, validar la narrativa del caso de uso y facilita la creación de los diagramas de secuencia.

El resultado del análisis robusto es un diagrama de colaboracion con el detalle de la secuencia de llamadas entre objetos que participan en un caso de uso.


Elementos del análisis robusto:




Boundary o Interfaz de usuario – Son objetos “Que muestran o piden datos”. Representa una pantalla, ventana, página, reporte.
Service o Control – Son objetos “Que hacen”. Son componentes que invocan, coordinan a otros objetos, realizan calculos, consultan o modifican objetos de negocio.
Entity u Objeto de Negocio – Son objetos “Que son”. Son los objetos detectados en el modelo de dominio, casi siempre son persistentes, es decir, se guardan en un repositorio de datos.


Reglas:
  • Para poder hacer este análisis es imprescindible tener la narrativa el caso de uso y las Clases de Negocio.
  • Se toma un caso de uso y se coloca el actor que inicia la funcionalidad del caso de uso.
  • Todo actor que inicie una interaccion con el sistema debe iniciar con un objeto Boundary.
  • Los Boundaries se detectan en la narrativa de casos de uso cuando se mencionan los conceptos: Pantalla, Página, Ventana. Si en la narrativa no se detecta un boundary inicial entonces hay un error en el caso de uso.
  • Los Servicios se detectan cuando en el caso de uso se menciona: “El Sistema realiza, El sistema ejecuta”
  • Los Entities son las clases de negocio u objetos del modelo de dominio que se detectaron con el análisis CRC
  • La interaccion se indica trazando una línea entre los objetos y se coloca un número y el nombre del mensaje a lado del la línea.
  • El acceso a un objeto entity se hace a través de un objeto service.Las operaciones CRUD son realizadas directamente por los objetos entity, mas adelante se refina el diseño y estas operaciones se asignan a un DAO.





Por el momento no coloque un ejemplo pero se proporcionan links de referencia para más detalle.

Analisis CRC
http://www.agilemodeling.com/artifacts/crcModel.htm

Análisis de Robustez
http://www.codeproject.com/KB/architecture/ModelViewController.aspx http://www.agilemodeling.com/artifacts/robustnessDiagram.htm