Análisis. Actividades. Por Miguel y Michael Bruegge, B., Dutoit, A. Object-Oriented Software Engineering. 3 Ed. Prentice Hall, 2009. Capítulo 5; numerales 5.4.6 á 5.4.12, 5.5; pp. 190 á 206

Identificación de Asociaciones Los diagramas de clase-> representacion de asociaciones entre objetos Una asociación muestra una relación entre dos o mas clases.

Identificación de asociaciones VENTAJAS 1. Clarifica el modelo de análisis 2. descubre casos limite asociados con enlaces.

PROPIEDADES DE LAS ASOCIACIONES Un nombre: describe la asociación Un rol en cada extremo identifica la función de cada clase con respecto a las asociaciones Una multiplicidad en cada extremo: identifica el posible numero de instancias

EJEMPLO Un nombre: Escribe Un rol en cada extremo: autor (fieldofficer) Una multiplicidad en cada final:* (fieldofficer), 1 (EmergencyReport)

HEURISTICA PARA IDENTIFICACION DE ASOCIACIONES Examine frases de verbo Nombre asociaciones y roles precisamente Use calificadores tan a menudo como sea posible para identificar espacio de nombres y atributos claves Eliminar cualquier asociación que pueda ser derivada de otras asociaciones. No se preocupe de la multiplicidad hasta que el juego de asociaciones sea estable. Evite modelos de ravioles: Demasiadas asociaciones hacen un modelo ilegible.

EJEMPLO La asociación entre incident y el fieldofficer no es necesaria.

Identificando Atributos Los atributos son propiedades de objetos individuales. Unicamente los atributos relevantes a el sistema deben ser considerados. Se debe identificar tantas asociaciones como sea posible antes de identificar atributos

EJEMPLO Atributos de la clase reporte de emergencia

Propiedades de los atributos Un nombre: que los identifica dentro de un objeto Una breve descripción Un type describe los valores legales que este puede tomar

Heurísticas para identificar atributos Examine frases posesivas Represente el estado almacenado como atributos de objeto entidad. Describa cada atributo No represente un atributo como un objeto, use una asociación en cambio No gaste el tiempo describiendo detalles finos antes de que la estructura de objeto sea estable.

Identificacion de agregados Las agregaciones son tipos especiales de asociaciones denonatas con una relacion parte entera

Tipos de agregados Existen dos tipos de agregacion: Composicion Compartida

COMPOSICION Es denotada por un diamante solido. Indica que la existencia   de las   partes depende de el todo Adiciona informacion sobre como los conceptos estan contenidos en el dominio de la aplicación

EJEMPLO

compuesta Denotada por un diamante hueco Indica que el todo y las partes pueden existir independientemente

EJEMPLO

Modelado Estado-dependiente comportamiento de objetos individuales Diagramas de secuencia-> Representa el comportamiento de el sistema desde la perspectiva de un unico caso de uso Diagramas de estado:Representa el comportamiento desde la perspectiva de un unico objeto

Diagrama de estado No es necesario construir diagramas de estado por cada clase en el sistema Objetos con una duración extendida de vida y comportamiento estado-dependiente

EJEMPLO Grafico de estado UML para incidente

MODELADO DE RELACIONES DE HERENCIA ENTRE OBJETOS La generalizacion es usada para eliminar redundancia desde el modelo de analisis Si dos clases comparten atributos o comportamiento las similitudes son consolidadas en una superclase

MODELADO DE RELACIONES DE HERENCIA ENTRE OBJETOS Ejemplo: Diagrama de clase UML relación de herencia

REVISION DEL MODELO DE ANALISIS La etapa de revisión comienza cuando el modelo de análisis se vuelve estable La revisión se realiza primero por los desarrolladores, y luego por cliente y desarrolladores

Objetivos de la revision de requerimientos Especificacion de requerimientos sea correcta,completa, consistente y sin ambiguedades Los requerimientos sean realistas y verificables

Preguntas utiles para asegurarse que el modelo sea correcto ¿Es el glosario de los objetos entidad comprensible pora el usuario? ¿Las clases abstractas corresponden a los conceptos de nivel de usuario? ¿Son todas las descripciones de conformidad con las definiciones de los usuarios? ¿Todos los objetos entidad y de frontera tienen significativas frases sustantivas como nombres? ¿ Todos los objetos de caso de uso y control tienen significativas frases verbales como nombres? ¿Están todos los casos de error descritos y manejados?

Preguntas utiles para asegurarse que el modelo sea completo Objeto: Es necesario para cualquier caso de uso? En cual caso de uso es creado? Modificado? Destruido?Puede este ser accesado desde un objerto divisorio? Atributo: Cuando Se Fija? Cual es su tipo? deberia ser un calificador? Asociacion: Cuando es atravesado? Por ue fue elegida la multiplidad escogida? ¿Pueden las asociaciones con multiplicidad de uno a muchos y muchos-a-muchos calificar? Objeto Control: ¿Tiene las asociaciones necesarias para acceder a los objetos que participan en su caso de uso correspondiente?

Preguntas utiles para asegurarse que el modelo sea consistente ¿Hay varias clases o casos de uso con el mismo nombre? Entidades (por ejemplo, casos de uso, clases, atributos) con similares nombres denotan similares conceptos? ¿Hay objetos con atributos similares y asociaciones que no están en la misma generalización jerargica?

Preguntas utiles para asegurarse que el sistema descrito por el modelo de analisis es realista Hay caracteristicas de novela en el sistema Fueron todos los estudios y prototipos construidos para su viabilidad? Pueden los requisitos de rendimiento y fiabilidad ser reunidos? Fueron estos requisitos verificados por cualquier prototipo ejecutandose en el hardware seleccionado?

RESUMEN ANALISIS La actividad de obtención de requerimientos es altamente iterativa e incremental.  Trozos de funcionalidad son esbozados  y propuestos a los usuarios y el cliente El cliente adiciona requerimientos, critica a la funcionalidad existente , y modifica los requisitos existentes.

Los desarrolladores investigan requisitos no funcionales RESUMEN ANALISIS Los desarrolladores  investigan requisitos no funcionales  Inicialmente, la obtención de requisitos se asemeja a una actividad de lluvia de ideas La descripción del sistema crece y los requerimientos se vuelven más concretos-> se amplia y  modifica el modelo de análisis en una manera más ordenada a través de prototipos y  estudios de tecnología y el reto de cada requisito propuesto. Como, los desarrolladores necesitan

ACTIVIDADES DE ANALISIS

Manejo del Análisis El fin del análisis de requerimientos es que se cree un documento que pueda ser escrito de forma coherente y pueda ser entendido por cualquier persona. Con la ing del software se intenta acotar el riesgo de fracaso

Manejo del Análisis Lo que se busca en la gestión de requerimientos en un proyecto es mantener la coherencia al utilizar tantos recursos Al final en el documento de análisis de requerimientos debe describirse un sistema único coherente entendible.

Manejo del Análisis El análisis de gestión se lleva acabo a través de las siguientes etapas: Análisis de documentación Asignación de responsabilidades La comunicación sobre análisis Iterar sobre el modelo de análisis Cliente registrado-no registrado

1. Análisis de la documentación Se centra en el RAD(Requirements Analysis Document) en el cual están documentados la obtención de requerimientos y las actividades de análisis. El RAD terminado y publicado es la línea base y es sometido a la configuración de gestión

1. Análisis de la documentación Modelos de objetos Modelos dinámicos MODELO DE OBJETOS: se documenta en detalle todos los objetos que identificamos, sus atributos, y usamos diagrama de secuencias, donde cada objeto es descrito con definiciones textuales, relaciones entre ilustraciones con diagrama de clases. MODELOS DINAMCOS: se documenta el comportamiento de los modelos de objetos en términos de diagramas de máquinas de estado y diagramas de secuencia. Aunque esta información es dredundante con los casos de uso, modelos dinámicos, nos representa mas complejidad, incluyendo muchos actores.

1. Análisis de la documentación RAD-Esquema General 1. Introduction 2. Current system 3. Proposed system 3.1 Overview 3.2 Functional requirements 3.3 Nonfunctional requirements 3.4 System models 3.4.1 Scenarios 3.4.2 Use case model 3.4.3 Object model 3.4.3.1 Data dictionary 3.4.3.2 Class diagrams 3.4.4 Dynamic models 3.4.5 User interface-(navigational paths and screen mock-ups) 4. Glossary Overview-objetivos[[ current system

2. Asignación de responsabilidades El análisis requiere de la participación de una amplia gama de individuos. Los individuos participan en el análisis mediante la asignación de roles y alcances bien definidos. Existen tres tipos principales de roles: Generación de información Integración Revisión

2. Asignación de responsabilidades Usuario final: Es el experto del dominio de la aplicación, es quien genera información del sistema actual, el entorno del futuro sistema y las tareas que debería apoyar El cliente: Participa en un rol de integración, define el ámbito de aplicación de el sistema, basado en los requerimientos del usuario

2. Asignación de responsabilidades El analista: Es experto en el dominio de aplicación quien modela el sistema actual y genera información sobre el futuro sistema El arquitecto: Participa en un rol de integración, unifica los casos de uso y modelos de objeto de un punto de vista del sistema

2. Asignación de responsabilidades El analista: Es experto en el dominio de aplicación quien modela el sistema actual y genera información sobre el futuro sistema. El arquitecto: Participa en un rol de integración, unifica los casos de uso y modelos de objeto de un punto de vista del sistema

2. Asignación de responsabilidades Editor de documento: Es responsable por la integración bajo-nivel de el documento y por el formato general de el documento y su índice Administrador de configuración: Es el responsable de mantener un historial de revisión de el documento así como información de trazabilidad relacionando la RAD con otros documentos El revisor: valida la RAD para correcciones, integridad, consistencia, y claridad

2. Asignación de responsabilidades En todos los casos debe haber un rol integrador en el lado del cliente y otro en el lado del desarrollo Al final, los requerimientos, a pesar de que agranden el sistema, deben ser entendibles por un solo individuo conocedor de el dominio de la aplicación.

3. Comunicación sobre el análisis Es una tarea mas difícil durante la obtención de requerimientos y el análisis debido a los siguientes factores: Diferente procedencia de los participantes(experiencia y vocabulario) Diferentes expectativas de los interesados(objetivos al definir el sistema)

3. Comunicación sobre el análisis Nuevos equipos(nuevo proyecto-aprender a trabajar juntos) Evolución del sistema(términos y conceptos en flujo)

3. Comunicación sobre el análisis Nuevos equipos(nuevo proyecto-aprender a trabajar juntos) Evolución del sistema(términos y conceptos en flujo)

Pautas simples para la gestión de la complejidad de puntos de vista conflictivos del sistema Ningún método de requerimientos o mecanismo de comunicación puede resolver problemas relacionados con políticas internas y ocultación de información, por ello se debe tener en cuenta las siguientes pautas simples de gestión:

Pautas simples para la gestión de la complejidad de puntos de vista conflictivos del sistema Definir claramente los territorios: Definición de roles y foros de discusión Definir objetivos claros y criterios de éxito: La coodefinicion de objetivos claros, medibles y verificables y criterios de éxito por parte del cliente y el desarrollador facilita la resolución de conflictos. Lluvia de ideas

4. Iterar sobre el modelo de análisis El análisis ocurre iterativamente e incrementalmente, frecuentemente en paralelo con otras actividades de desarrollo Debe tenerse en cuenta que la modificación y extensión del modelo de análisis sin restricciones únicamente puede resultar en caos; por ello se utiliza el control de cambios

4. Iterar sobre el modelo de análisis La actividad de requerimientos puede ser vista como varios pasos convergiendo hacia un modelo estable. Estos pasos son: Lluvia de ideas: todo cambia ->generar tantas ideas como sea posible->iteraciones rápidas y de largo alcance Solidificación: clientes y desarrolladores convergen en una idea común->definición de los limites del sistema y conjunto de términos estándar . Funcionalidad organizada en grupos de casos de uso con sus correspondientes interfaces-> Grupos de funcionalidad son asignados a diferentes equipos que son responsables por detallar sus correspondientes casos de uso Iteraciones rápidas pero localizadas

4. Iterar sobre el modelo de análisis Madurez: Responsabilidad de equipos de funcionalidad(casos de uso y objetos) cada cual con representantes en el equipo arquitectura(integración de requerimientos) Cuando los requerimientos son firmados por el cliente-> las medicaciones al modelo de análisis deben direccionarse a omisiones y errores Asegurar la consistencia del modelo El modelo de requerimientos esta bajo gestión de configuración y los cambios deben ser propagados a modelos de diseño existentes Las iteraciones son lentas y frecuentemente localizadas

5. Firma del cliente La firma del cliente representa la aceptación del modelo de análisis por el cliente. El cliente y los desarrolladores convergen en una única idea y están desacuerdo con las funciones y características que el sistema tendrá. Además ellos están desacuerdo con: una lista de prioridades un proceso de revisión una lista de criterios que se utilizarán para aceptar o rechazar el sistema un calendario y un presupuesto

Prioridad de funciones Dar prioridad a las funciones del sistema permite a los desarrolladores entender mejor las expectativas del cliente con lo cual se puede separar ruido de características esenciales y además permite entregar el sistema en bloques incrementales Ejemplo de esquema de prioridad: Cada función se asignará una de las siguientes prioridades Prioridad Alta –Una característica alta-prioridad debe ser demostrada con éxito durante la aceptación del cliente Prioridad media: Una característica prioridad-media debe tenerse en cuenta en el diseño del sistema y diseño del objeto. Esta será implementada y demostrada en la segunda iteración de el desarrollo del sistema Prioridad baja: ilustra como el sistema podría ampliarse a mas largo plazo