Requerimientos1

1. INGENIERÍA DE REQUERIMIENTOS2ª- PARTE NOTAS DEL CURSO: C121 INGENIERIA DE SOFTWARE I DRA. MARIA DEL PILAR GÓMEZ GIL OTOÑO 2012 Versión: 15 Oct.- 2012

2. Mas sobre documentación de Requerimientos [Wiegers 2003] • Los requerimientos funcionales y no funcionales del producto de software a fabricarse se encuentran en un documento conocido como SRS (software requirements specification).

3. Quienes usan el SRS? [Wiegers 2003] • Clientes – Para ver que tipo de producto les será entregado • Administradores del proyecto – para realizar sus estimaciones • Desarrolladores, equipo de mantenimiento – para saber que deben construir • Probadores – para hacer planes, procedimientos y casos de prueba • Capacitores, staff del area legal, sub-contratadores, documentitstas etc.

4. Baselining • Proceso de transformar un SRS en desarrollo, a uno que ha sido revisado y aprobado • Es importante que todo el equipo trabaje con el mismo conjunto de requerimientos

5. Sugerencias para escribir requerimientos (1/3) • Etiquete secciones, subsecciones y requerimientos individuales de forma consistente • No justifique “a la derecha” • Deje suficientes espacios en blanco • Enfatice las palabras clave usando “negritas”, “italica” o fonts diferentes, de manera consistente y sensata.

6. Sugerencias para escribir requerimientos (2/3) • Genere una tabla de contenido e indices para facilitar el encontrar información • Numere todas las figura y las tablas, pongales título (o encabezado en caso de figuras) y haga referencia a éstas con un número

7. Sugerencias para escribir requerimientos (3/3) • Cuando haga referencia a alguna sección dentro del documento, utilice las facilidades de “referencias cruzadas” y numeración automática del procesador de palabras, en vez de teclear directamente los números • Use hiper-ligas para permitir al lector saltar a una sección, o a otro documento. • Use una plantilla para organizar toda la información.

8. Identificación de los requerimientos • Todo requerimiento debe estar identificado de manera única y persistente, a fin de facilitar su seguimiento (traceatbility), modificación y re-uso en otros proyectos • Estrategias de identificación • Número secuencias único y no re-usable • Numeración jerárquica • Numeración jerárquica usando texto • Para textos no definidos, se usa la etiqueta TBD (tobedetermined)

9. Plantilla propuesta por Wiegers (2003)

10. Guías para escribir requerimientos • Ver [Wiegers 2003]

11. Diccionario de datos • Usados para definir los flujos de información • Basados en los BNF’s (BakusNausforms) • Muy útiles para definir información • Símbolos usados: • + composición (AND) • 1 separación componente alternativo (OR) • { } repetición • [] agrupación de componente alternativo o primitivas posibles • ( ) componente opcional • x { } y x:y{} iteración desde x hasta y (x, y opcionales) • * Inicio y fin de comentarios

12. Diccionario de datos (2/2) • Escribirlos en una tabla, en orden alfabético, identificando el elemento “raiz” • Definir tanto como sea necesario para entender el significado del flujo de dato. • Ejemplo

13. Proceso Unificado [Jacobson et al., 2000]

14. Actividad de Análisis • La especificación de requerimientos tiene que estar escrita de tal manera que sea entendida por los usuarios, sin ser demasiado técnica, pero al a vez sea suficientemente clara, completa y detallada para los diseñadores

15. Estrategia de Solución • La especificación contiene una estrategia de solución, escrita por el equipo de software • Varias estrategias de solución pueden ser analizadas y descartadas. • Es importante registrar el porque una estrategia es rechazada. Esta información servirá para aclaraciones futuras y para evitar que decisiones no adecuadas se repitan en el futuro

16. Objetivos de la actividad de análisis en el Proceso Unificado • Desde el punto de vista de la actividad de requerimientos, el objetivo es entender mas profundamente los requerimientos • Desde el punto de vista de la actividad de diseño e implementación, el objetivo es describir los requerimientos de tal manera que el diseño e implementación resultante sean fáciles de mantener

17. El camino puede ser definir clases y objetos involucrados en el sistema…. El conjunto de clases en un sistema y sus relaciones definen lo que se conoce como el Modelo del Sistema

18. Recordando… Objeto: Cualquier cosa, real o abstracta, que es descrito por un conjunto de atributos y será manipulado dentro del software a través de métodos.

19. Características importantes • Cada instancia de un objeto (ejemplo un libro) puede ser identificada (ejemplo # ISBN) de manera única. • Cada objeto desempeña una función necesaria en el sistema; el sistema no podría funcionar sin el acceso a las instancias del objeto • Cada objeto es descrito por atributos.

20. Objeto de Datos y Atributos Un objeto de datos contiene un conjunto de atributos que determinan aspectos, cualidades, características o descripciones de éste Objeto: automóvil Atributos: marca modelo tipo de carrocería precio opciones de código

21. Otros Conceptos Básicos sobre Objetos • TIPO DE OBJETO: Es una categoría de objeto. Un objeto es una instancia de un tipo de objeto. • ATRIBUTOS: Características que definen a un objeto. • MÉTODOS: Especificación de la forma en que se controlan los datos de un objeto. • ENCAPSULADO: Es el empaque de datos y métodos, resultado de ocultar los detalles de implantación de un objeto respecto de su usuario.

22. Conceptos Básicos (continuación...) • MENSAJE: Es una solicitud para que se lleve a cabo una operación. Puede utilizar uno o más objetos como parámetros • CLASE: Es una implantación en software de un tipo de objeto. Especifica una estructura de datos y los métodos operativos permisibles que se aplican a cada uno de sus objetos. • HERENCIA: Las instancias heredan las características de las clases a las que pertenecen. Las clases heredan características de las super-clases, etc.

23. Pasos Para Encontrar Objetos • La mayoría de las metodologías orientadas a objetos tienen un conjunto básico de actividades para definir objetos, las cuales incluyen: • Identificación de objetos • Identificación de Atributos • Definición de operaciones • Comunicación entre objetos • Integración final de la definición.

24. Paso 1. Identificación de Objetos • Se puede empezar con la identificación de objetos haciendo una revisión de tipo gramatical sobre los componentes narrativos de la especificación de requerimientos. • Los objetos pueden ser los sustantivos o cláusula • sustantivas de la narrativa. • Los objetos pueden manifestarse en alguna de las siguientes formas:

25. Formas de Objetos • Entidades Externas que producen o consumen información a utilizarse por un sistema basado en computadora. (ejemplo: otros sistemas, dispositivos, personas.) • Cosas que son parte del dominio de información para el problema (ejemplo: reportes, despliegues, letras, señales). • Ocurrencias o eventos que ocurren dentro del contexto de operación del sistema (ejemplo: transferencia de propiedad, la terminación de una serie de movimientos de un robot continúa…

26. Formas de Objetos (continuación...) • Unidades organizacionales que son relevantes a una aplicación (ejemplo: división, grupo) • Lugares que establecen el contexto del problema y la función general del sistema. (ejemplo piso de manufactura o andén de carga) • Estructuras que definen una clase de objetos o clases de objetos relacionados

27. Selección de Objetos Para que un objeto se incluya en el modelo del sistema debe satisfacer todas (o casi todas) las siguientes características: • Información retenida. El objeto potencial será útil durante el análisis solo si debe recordarse información acerca de él para que el sistema pueda funcionar. • Servicios Requeridos. El objeto potencial debe tener una serie de operaciones identificables que puedan cambiar el valor de sus atributos • Atributos múltiples. Un objeto con un solo atributo tal vez no sea muy útil como objeto, sino que probablemente será mejor representarlo como atributo de otro objeto.

28. Selección de Objetos (continuación...) • Atributos Comunes. Se puede definir un conjunto de atributos para el objeto potencial, y éstos se aplican a todas las ocurrencias del objeto. • Operaciones comunes. Se puede definir un conjunto de operaciones para el objeto potencial, y estas se aplican a todas las ocurrencias del objeto. • Requerimientos esenciales. Las entidades externas al sistema que producen o consumen información esencial en su solución, generalmente se definen como objetos.

29. Un ejemplo de Identificación de Objetos NARRATIVA: El softwareCasaSegura permite que el dueño de la casa configure el sistema de seguridad una vez que éste se ha instalado. Además, el software permite monitorear todos los sensores conectados al sistema de seguridad e interactuar con el dueño de la casa a través de un panel de control. Durante la instalación, el panel de control de CasaSegura se utiliza para programar y configurar el sistema. Cada sensor tiene asignado un número y tipo; se programa una contraseña maestra para conectar y desconectar el sistema, y se proporciona un número telefónico que se marcará cuando algún evento sensado ocurra.

30. Narrativa(continuación...) Cuando un evento es percibido por el software, éste hace sonar una alarma audible conectada al sistema. Después de un tiempo de espera que es especificado por el dueño durante la configuración del sistema, el software marca un número de teléfono de un servicio de monitoreo, dando información acerca de la localización, y reporta la naturaleza del evento que se ha detectado. El número se marcará cada 20 segundos, hasta que la conexión telefónica se obtenga. Toda interacción con Casa Segura se maneja a través de un subsistema de interacción con el usuario que lee entradas a través del teclado y despliega mensajes e información del estatus en la pantallaLCD. La interacción con el teclado sigue de la siguiente manera: …

31. Objetos Potenciales del Ejemplo

32. SISTEMA PANEL DE CONTROL SENSOR ALARMA AUDIBLE EVENTO PERCIBIDO Objetos Identificados en el ejemplo

33. Pasos Para Encontrar Objetos • La mayoría de las metodologías orientadas a objetos tienen un conjunto básico de actividades para definir objetos, las cuales incluyen: • Identificación de objetos • Identificación de Atributos • Definición de operaciones • Comunicación entre objetos • Integración final de la definición.

34. SENSOR tipo numero de sensor limite respuesta Paso 2: Identificación de atributos • Los atributos son en esencia los que definen al objeto clasificado según su significado en el contexto del sistema. • Un objeto puede tener diferentes atributos dependiendo del sistema en que esté siendo utilizado. • Para determinar atributos, contestar la pregunta: “Qué elementos de datos (compuestos o elementales) definen completamente este objeto en el contexto del sistema?” Ejemplo:

35. Paso 3. Definición de Operaciones • Una operación cambia los valores de uno o más atributos de un objeto. Una operación debe tener conocimiento de los atributos del objeto. • Hay tres tipos de operaciones: • Las que manipulan datos (añadir, borrar, dar forma) • Las que realizan cálculos • Las que monitorean un objeto para determinar la ocurrencia del evento

36. Definición de Operaciones (continuación) • Para encontrar las operaciones de un objeto, se puede realizar una revisión sobre la narrativa del sistema, buscando los verbos. • También se pueden identificar operaciones analizando la comunicación que existe entre objetos. • Ejemplo: “... Cada sensor tiene asignado un número y un tipo; se programa una contraseña maestra_para conectar y desconectar el sistema,...” Se identifican las operaciones: Asignar_número() Programar_contraseña()

37. Pasos Para Encontrar Objetos • La mayoría de las metodologías orientadas a objetos tienen un conjunto básico de actividades para definir objetos, las cuales incluyen: • Identificación de objetos • Identificación de Atributos • Definición de operaciones • Comunicación entre objetos • Integración final de la definición.

38. Paso 4: Comunicación entre Objetos • Para construir el sistema es necesario definir un mecanismo de comunicación entre objetos. • Los mensajes tienen la forma: mensaje: (destino, operación, argumentos) • Los mensajes son importantes en la implementación del sistema, pero no se requiere considerarlos a detalle durante el análisis del sistema; aquí ayudan a determinar candidatos de atributos.

39. Paso 5: Integración final de la Definición • Se pueden definir operaciones adicionales considerando la “historia de la vida” de los objetos y los mensajes que circulan entre ellos. • La “historia de vida” de un objeto se puede definir considerando que un objeto se crea, se modifica, se manipula, se lee, y posiblemente se elimina.

40. ¿ Qué es una Relación? • Relación – indica conectividad , un “hecho” que debe ser “recordado” por el sistema y no puede ser o no es calculado o derivado mecánicamente. • Pueden existir varias instancias en una relación. • Los objetos pueden estar relacionados de muchas maneras diferentes.

41. Cardinalidad y Modalidad • CARDINALIDAD: es la especificación del número de ocurrencias de un objeto que se relaciona con ocurrencias de otro. • Se expresa normalmente como “uno” o “muchos”. Ejemplo: Un marido tiene una esposa Un padre tiene muchos hijos

42. Tipos de Cardinalidad: • Uno a uno (1:1) – Una ocurrencia del objeto A se puede relacionar a una y solo una ocurrencia del objeto B. • Uno a muchos (1:N) – Una ocurrencia del objeto A se puede relacionar a una o muchas ocurrencias del objeto B, pero una de B se puede relacionar sólo a una del objeto A. • Muchos a muchos (M:N) – Una ocurrencia del objeto A puede relacionarse con una o más ocurrencias de B, mientras que una de B se puede relacionar con una o más de A.

43. Modalidad • Indica si hay o no una necesidad explícita de que ocurra una relación, o que sea opcional. • La modalidad es “uno” si una ocurrencia de relación es obligatoria.

44. Un ejemplo de diagrama entidad-relación Solicita Cliente Servicio 1 m 1 Orden de Trabajo Genera Tabla de tareas estándar n 1 1 Seleccionadas de 1 Consiste de Pruebas de Trabajo w w n Genera listas Materiales

45. Descripción de un Modelo Conceptualusando UML • Básicamente se definen clases y sus relaciones

46. Ejemplo [Larman 1999]

47. Actividad de Análisis en el Proceso Unificado (UP) • UP es dirigido por casos de uso. • Durante el análisis los casos de uso se describen en términos de clases. • UP tiene 3 tipos de clases: • Clases de entidad: modelan información que tendrá “larga vida” en el sistema • Clases de fronteras (boundary classes): modelan la interacción entre el producto de software y sus actores, normalmente asociadas con entradas y salidas • Clases de control: modelan algoritmos y cálculos complejos

48. Pasos de UP para realizar la actividad de análisis • Repite • Realizar modelado funcional • Realizar modelado de clases • Realizar modelado dinámico hasta que las clases de identidad hayan sido extraídas satisfactoriamente. • Extrae las clases de frontera y las clases de control • Refina los casos de uso • Realiza los casos de uso (extenderlos y refinarlos)

49. Pasos en UP para extracción de clases • Modelado de funciones (hacer escenarios) • Modelado de clases de entidad (a través de extracción de sustantivos) • Modelado dinámico (genera diagramas de estados)

50. Ejemplo de un diagrama de clases de identidad (tomado de Schach 2008)