Fase de análisis orientado a objetos
Páginas: 6 (1337 palabras)
Publicado: 8 de enero de 2012
1. FASE DE ANÁLISIS ORIENTADO A OBJETOS.
2.1. 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.
2.2. Análisis del dominio.
El análisis en sistemas orientados a objetos puede ocurrir a muchosniveles diferentes de abstracción nivel de negocios o empresas, las técnicas asociadas con el AOO pueden acoplarse con un enfoque de ingeniería de la información en un esfuerzo por definir
Clases, objetos, relaciones y comportamientos que modelen el negocio por completo. A nivel de áreas de negocios, puede definirse un modelo de objetos que describa el trabajo de un área específica de negocios (ouna categoría de productos o sistemas).A nivel de las aplicaciones, el modelo de objetos se centra en los requisitos específicos del cliente, pues éstos afectan a la aplicación que se va a construir.
2.3. Componentes genéricos del modelo de análisis orientado a objetos.
Se ocupa de proyectar un modelo preciso, conciso, comprensible y correcto del mundo real.
El propósito de análisisOrientado a objetos es modelar el mundo real de forma tal que sea comprensible. Para esto se deben examinar los requisitos, analizar las implicaciones que se deriven de ellos y reafirmarlos de manera rigurosa. Se deben abstraer primero las características del mundo real y dejar los pequeños detalles para más tarde.
2.4. El proceso del análisis orientado a objetos (AOO).
El proceso de AOOcomienza con una comprensión de la manera en la que se usará el sistema: por las personas, si el sistema es de interacción con el hombre; por otras máquinas, si el sistema está envuelto en un control de procesos; o por otros programas; si el sistema coordina y controla otras aplicaciones. Una vez que se ha definido el escenario, comienza el modelado del software.
Las secciones que siguendefinen una serie de técnicas que pueden usarse para recopilar requisitos básicos del usuario y después definen un modelo de análisis para un sistema orientado a objetos.
2.5.1. Caso de estudio.
Los casos de uso modelan el sistema desde el punto de vista del usuario. Creados durante la obtención de requisitos, los casos de uso deben cumplir los siguientes objetivos: definir losrequisitos funcionales y operativos del sistema (producto), diseñando un escenario de uso acordado por el usuario final, y el equipo de desarrollo; proporcionar una descripción clara y sin ambigüedades de cómo el usuario final interactúa con el sistema y viceversa, y proporcionar una base para la validación de las pruebas.
2.5.2. Modelado de clases – responsabilidades – colaboraciones.
Elmodelado de clases-responsabilidadescolaboraciones (CRC) WIR90 aportaun medio sencillo de identificary organizar las clasesqueresulten relevantes al sistema o requisitos del producto. Ambler AMB95 describe el modeladoCRC 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 secciones.A lo largo dela cabecera de la tarjeta usted escribe el nombre de la clase. En el cuerpo se listan las responsabilidades de la clase a la izquierda y a la derecha los colaboradores.
Clases: los objetos se manifiestan en una variedad de formas entidades externas, cosas, ocurrencias o sucesos, roles, unidades organizativas, lugares, o estructuras
Un objeto potencial debe satisfacer estas seiscaracterísticas para poder ser considerado
como posible miembro del modelo:
retener información: el objeto potencial será útil durante el análisis si la información sobre el mismo debe guardarse para que el sistema funcione.
2. Servicios necesarios: el potencial objeto debe tener un conjunto de operaciones identificables que permitan cambiar los valores de sus atributos.
3. Múltiples...
2.1. 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.
2.2. Análisis del dominio.
El análisis en sistemas orientados a objetos puede ocurrir a muchosniveles diferentes de abstracción nivel de negocios o empresas, las técnicas asociadas con el AOO pueden acoplarse con un enfoque de ingeniería de la información en un esfuerzo por definir
Clases, objetos, relaciones y comportamientos que modelen el negocio por completo. A nivel de áreas de negocios, puede definirse un modelo de objetos que describa el trabajo de un área específica de negocios (ouna categoría de productos o sistemas).A nivel de las aplicaciones, el modelo de objetos se centra en los requisitos específicos del cliente, pues éstos afectan a la aplicación que se va a construir.
2.3. Componentes genéricos del modelo de análisis orientado a objetos.
Se ocupa de proyectar un modelo preciso, conciso, comprensible y correcto del mundo real.
El propósito de análisisOrientado a objetos es modelar el mundo real de forma tal que sea comprensible. Para esto se deben examinar los requisitos, analizar las implicaciones que se deriven de ellos y reafirmarlos de manera rigurosa. Se deben abstraer primero las características del mundo real y dejar los pequeños detalles para más tarde.
2.4. El proceso del análisis orientado a objetos (AOO).
El proceso de AOOcomienza con una comprensión de la manera en la que se usará el sistema: por las personas, si el sistema es de interacción con el hombre; por otras máquinas, si el sistema está envuelto en un control de procesos; o por otros programas; si el sistema coordina y controla otras aplicaciones. Una vez que se ha definido el escenario, comienza el modelado del software.
Las secciones que siguendefinen una serie de técnicas que pueden usarse para recopilar requisitos básicos del usuario y después definen un modelo de análisis para un sistema orientado a objetos.
2.5.1. Caso de estudio.
Los casos de uso modelan el sistema desde el punto de vista del usuario. Creados durante la obtención de requisitos, los casos de uso deben cumplir los siguientes objetivos: definir losrequisitos funcionales y operativos del sistema (producto), diseñando un escenario de uso acordado por el usuario final, y el equipo de desarrollo; proporcionar una descripción clara y sin ambigüedades de cómo el usuario final interactúa con el sistema y viceversa, y proporcionar una base para la validación de las pruebas.
2.5.2. Modelado de clases – responsabilidades – colaboraciones.
Elmodelado de clases-responsabilidadescolaboraciones (CRC) WIR90 aportaun medio sencillo de identificary organizar las clasesqueresulten relevantes al sistema o requisitos del producto. Ambler AMB95 describe el modeladoCRC 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 secciones.A lo largo dela cabecera de la tarjeta usted escribe el nombre de la clase. En el cuerpo se listan las responsabilidades de la clase a la izquierda y a la derecha los colaboradores.
Clases: los objetos se manifiestan en una variedad de formas entidades externas, cosas, ocurrencias o sucesos, roles, unidades organizativas, lugares, o estructuras
Un objeto potencial debe satisfacer estas seiscaracterísticas para poder ser considerado
como posible miembro del modelo:
retener información: el objeto potencial será útil durante el análisis si la información sobre el mismo debe guardarse para que el sistema funcione.
2. Servicios necesarios: el potencial objeto debe tener un conjunto de operaciones identificables que permitan cambiar los valores de sus atributos.
3. Múltiples...
Leer documento completo
Regístrate para leer el documento completo.