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






5 comentarios:

  1. Interesante post, yo solo he tenido la oprtunidad de experiemntar con UML, pero como tu indicas en oncasiones UML no es suficiente para detectar clases y diseniar completamente orientado a objetos. Estas tecnicas que indicas son interesantes y parecen complementar a los disenios con UML. Esto puede ser de gran ayuda a los desarroladores de software para crear disenios mucho mas robustos.

    ResponderEliminar
  2. Hola

    Espero en breve poder agregar ejemplos acerca de estas tecnicas.

    bye

    ResponderEliminar
  3. Que tal Jose Luis encontre tu blog cuando indagaba sobre SCEA, soy un estudiante de ingenieria y me gustaria obtener dicha certificacion sin embargo a la vez estoy un poco dudoso sobre la relevancia de obtenerla, te agradeceria que pudieras comentarme sobre tus experiencias o que me brindaras algun consejo personal me seria de gran ayuda.

    ResponderEliminar
  4. Pues te dire que son pocos los desarrolladores que optan por esta certificacion SCJD y por la SCEA, no por que no sea relevante o no sea solicitada sino por que implica un esfuerzo adicional a resolver un examen teorico.

    Pocas personas obtienen estas certificaciones y ese puede ser un factor de por que pocos reclutadores las conocen y te la piden.

    Te dire que ademas de aprobar vas a aprender que es lo minimo necesario en un sistema para que sea considerado un buen sistema diseñado y construido.

    Al realizar los proyectos de estas 2 certificaciones aprendi mas acerca de Diseño, aplicacion de patrones, practicas de programacion y revisiones de diseño.

    Checate los recursos que anote en la descripcion de estas certificaciones.

    Bye

    ResponderEliminar
  5. ok muchas gracias :)

    ResponderEliminar