Análisis. Actividades. Por Miguel y Michael

Presentación del tema: "Análisis. Actividades. Por Miguel y Michael"— Transcripción de la presentación:

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

2 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.

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

4 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

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

6 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.

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

8 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

9 EJEMPLO Atributos de la clase reporte de emergencia

10 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

11 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.

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

13 Tipos de agregados Existen dos tipos de agregacion: Composicion
Compartida

14 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

15 EJEMPLO

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

17 EJEMPLO

18 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

19 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

20 EJEMPLO Grafico de estado UML para incidente

21 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

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

23 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

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

25 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?

26 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?

27 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?

28 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?

29 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.

30 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

31 ACTIVIDADES DE ANALISIS

32 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

33 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.

34 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

35 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

36 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.

37 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 Data dictionary Class diagrams 3.4.4 Dynamic models 3.4.5 User interface-(navigational paths and screen mock-ups) 4. Glossary Overview-objetivos[[ current system

38 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

39 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

40 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

41 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

42 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

43 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.

44 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)

45 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)

46 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)

47 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:

48 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

49 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

50 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

51 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

52 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

53 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