Técnicas Orientadas A Objetos Para El Análisis De Requerimientos

3.2 TÉCNICAS ORIENTADAS A OBJETOS PARA EL ANÁLISIS DE REQUERIMIENTOS.
Las técnicas orientadas a objetos permiten que el software se construya a partir de objetos de compartimiento específico.
Los propios objetos se pueden constituir a partir de otros, que a su vez pueden estar formados por otros objetos. Esto nos recuerda a una máquina compleja construida por partes, subpartes y sub-subpartes,etc.


3.2.1 CARACTERÍSTICAS DEL ANÁLISIS ORIENTADO A OBJETOS.
El objetivo del análisis orientado a objetos es desarrollar una serie de modelos que describan el software de computadora al trabajar para satisfacer un conjunto de requisitos definidos por el cliente. El AOO, como los métodos de análisis convencionales descritos, forma un modelo de análisis multiparte para satisfacer esteobjetivo.
El modelo de análisis ilustra información, funcionamiento y comportamiento dentro del contexto de los elementos del modelo de objetos.


 
3.2.2 ESPECIFICACIÓN FORMAL DE OBJETOS.
No hay duda de que el modo de especificación tiene mucho que ver con la calidad de la solución. Los ingenieros del software que se han visto forzados a trabajar con especificaciones incompletas, inconsistentes oengañosas han experimentado la frustración y confusión que invariablemente provocan. La calidad, la fecha de entrega y el alcance del software son las que sufren las consecuencias.

Principios de la especificación:
La especificación, independientemente del modo como la realicemos, puede verse como un proceso de representación. Los requisitos se representan de manera que como fin último llevenal éxito de la implementación del software.

A continuación, se proponen algunos principios de especificación:
 Separar la funcionalidad de la implementación.
 Desarrollar un modelo del comportamiento deseado de un sistema que comprenda datos y las respuestas funcionales de un sistema a varios estímulos del entorno.
 Establecer el contexto en que opera el software especificando la manera enque otros componentes del sistema interactúan con él.
 Definir el entorno en que va a operar el sistema e indicar como una colección de agentes altamente entrelazados reacciona a estímulos del entorno.
 Reconocer que «la especificación debe ser tolerante a un posible crecimiento si no es completa». Una especificación es siempre un modelo una abstracción de alguna situación real (o prevista)que normalmente suele ser compleja. De ahí que será incompleta y existirá a muchos niveles de detalle.
 Establecer el contenido y la estructura de una especificación de manera que acepte cambios.

 
3.2.2.1 CASOS DE USO.
Un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización software. Cada caso de uso proporciona uno o más escenariosque indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico.
En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso. En otras palabras, un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propiosistema.
Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas.

3.2.2.2 MODELADO DE CLASES, RESPONSABILIDADES Y COLABORACIONES.
Una vez que se han desarrollado los escenarios de uso básicos para el sistema, es el momento de identificar las clases candidatas e indicar susresponsabilidades y colaboraciones. El modelado de clases-responsabilidades colaboraciones (CRC) aporta un medio sencillo de identificar y organizar las clases que resulten relevantes al sistema o requisitos del producto.
Se describe el modelado CRC de la siguiente manera:
Un modelo CRC es realmente una colección de tarjetas índice estándar que representan clases. Las tarjetas están divididas en tres...