E SCUELA ACADEMICO PROFESIONAL DE I NGENIERIA DE S ISTEMAS

1. ESCUELA ACADEMICO PROFESIONAL DE INGENIERIA DE SISTEMAS Curso : Ingeniería de Software Sesión 2 : PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

2. Temario ... Sesión 2 : PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE • Fases y modelos. • Modelo del Negocio. • Diagrama de actividades del negocio. • Casos de uso del negocio. • Modelos de objetos del negocio.

3. Fases y modelos ...

4. El Proceso Unificado Un proceso de software “guiadopor los casos de uso, centrado en la arquitectura, iterativo e incremental. Reconoce la importancia de la comunicación con el cliente y la orientacion a describir el punto de vista del cliente con respecto a un sistema (ejm el CdU). Enfatiza la importancia de la arquitectura de software, focalizandolasmetascorrectas, como el entendimiento, el ajuste a los cambiosfuturos y la reutilizacion” Plantea un flujo de procesoiterativo e incremental, concordando con la caracteristicaevolutiva del software moderno.

5. Fases del Proceso Unificado Lanzamiento Fig. Relación del Proceso Unificado con la actividades genéricas del marco de trabajo del proceso de software

6. Fases del ProcesoUnificado • INICIO • Comprende la comunicacióncon el cliente y lasactividades de planeación. • Propósito: definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.. • Los requisitosfundamentales del negocio se describen a travésde un conjuntopreliminar de Casos de Uso (CdU). • Los CdUdescribenlascaracterísticasy funcionesdeseables para cadaclaseimportante de usuarios. • ELABORACION • Se seleccionan los casos de uso que permiten definir la arquitectura base del sistema, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar. Expandela representacionarquitectónicapara incluir 5 visionesdiferentes del software: • El modelo de CdU • El modelo de análisis • El modelo de diseño • El modelo de implementación • El modelo de despliegue.

7. Fases del ProcesoUnificado CONSTRUCCION Desarrollao adquierelos componentes del software queharaquecadaCdU sea operativo para los usuarios finales. Se diseñan y ejecutanpruebas de unidad para cadacomponente. Se realizanlasactividades de integracion (ensamble de componentes y pruebas de integracion) TRANSICION Propósito: asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.. Al final de estafase, el incremento de software se convierte en un lanzamiento de software utilizable.

8. MODELADO DEL ANALISIS 2.1 Análisis de requisitos 2.2 Enfoques de modelado del análisis 2.3 Conceptos del modelado de datos 2.4 Análisis orientado a objetos. Conceptos 2.5 Modelado basado en escenarios 2.5.1 Especificación y Diagrama de Casos de Uso 2.5.2 Diagramas de actividad Mg. Ing. WILFREDO CARRANZA

9. MODELADO DEL ANALISIS La Ingeniería de Software comienza con una serie de tareas de modelado que conducen a una especificación de requisitos y a una representación completa del diseño del software que se construirá. El modelo de análisis, conformado por una serie de modelos, es la primera representación técnica del sistema. 2.1 Análisis de requisitos Por medio del modelado del análisis, el ingeniero de software se centra primero en el qué, no en el cómo. ¿Qué objetos manipula el sistema? ¿Qué funciones debe desempeñar el sistema? ¿Qué comportamientos muestra el sistema? ¿Qué interfaces se definen? Y, ¿Qué restricciones se aplican? Mg. Ing. WILFREDO CARRANZA

10. Fig.El modelo de análisis como un puente entre la descripción del sistema y el modelo de diseño Arquitectura de aplicación del SW Interfaz con el usuario Funcionalidad general del sistema (aplicando SW, HW, Datos, Humanos) Modelo de Diseño Modelo de Análisis Estructura en el nivel de componentes Descripción del sistema (llena el vacío entre una descripción al nivel de sistemas y el diseño de software) Y, otros elementos del sistema (Ejm: seguridad, rendimiento)

11. 2.2 Enfoquesdel modelado de analisis Una visión del modelado del análisis, llamado análisis estructurado, considera que los datos y el proceso que transforma los datos son entidades separadas. Los objetos de datos se modelan en una forma que define sus atributos y relaciones. Los procesos que manipulan los objetos de los datos se modelan de tal manera que muestran cómo transforman los datos, mientras los objetos de datos fluyen por el sistema. Un segundo enfoque del modelado del análisis, llamado análisis orientado a objetos, se centra en la definición de clases y en la manera en que éstas colaboran entre ellas para efectuar los requisitos del cliente. El UML y el proceso unificado están orientados a objetos en forma predominante.

12. 2.3 Conceptosdel modelado de datos El modelado del análisis a menudo comienza con el modelado de datos. El ingeniero o analista del software define todos los objetos de datos que se procesan dentro del sistema y las relaciones entre los objetos de datos, además de otra información pertinente para las relaciones. Objetos de datos Un objeto de datos es una representación de casi cualquier información compuesta que el software debe entender. Información compuesta se refiere a algo que tiene muchas propiedades o atributos diferentes. Un objeto de datos puede ser: una entidad externa (por ejem., cualquier cosa que produzca o consuma información), una cosa (por ejemplo, un reporte o un despliegue), un suceso (como una transacción bancaria o, una llamada telefónica) o un evento (como alerta por clave errada o, una alarma), un rol (por ejem., un comprador, un auditor), una unidad organizacional (como un departamento de logística), un lugar (como un almacén), o una estructura (como un archivo).

13. Por ejemplo, una persona o un auto pueden verse como un objeto de datos en el sentido de que cualquier de ellos puede definirse en términos de un conjunto de atributos. Un objeto de datos encapsula sólo datos: no existe alguna referencia dentro del objeto de datos a las operaciones que actúan sobre los datos. Une los objetos de datos entre si Atributos referenciales Atributos descriptivos Identificador Instancia Nombres de atributos

14. Atributos Los atributos definen las propiedades de un objeto de datos y toman una de las tres características diferentes. Se pueden utilizar para: 1) nombrar una ocurrencia de objeto de datos. 2) describir la ocurrencia, o 3) hacer referencia a otra ocurrencia en otra tabla. Además, se debe definir uno o más atributos como un identificador es decir, el atributo identificado se convierte en una “clave” cuando se desea encontrar una concurrencia del objeto de datos.

15. Relaciones Los objetos de datos están conectados entre si de muchas maneras diferentes. Por ejemplo, dos objetos de datos, persona y auto, pueden representarse con la simple notación ilustrada. Se establece una conexión entre persona y auto porque los objetos se relacionan entre sí. persona automóvil a) Una conexión básica entre objetos de datos posee persona automóvil autorizada para manejar b) Relaciones entre objetos de datos

16. … Conceptos del modelado de datos Cardinalidad y modalidad Se debe entender cuántas ocurrencias del objeto X están relacionadas con cuántas ocurrencias del objeto Y. Esto conduce al concepto del modelado de datos llamado cardinalidad. El modelo de datos debe ser capaz de representar el número de ocurrencias de los objetos en una relación dada. Ejm.: si un objeto puede relacionarse sólo con otro objeto entonces la relación es 1: 1 Y, si es con muchos objetos entonces la relación es 1:N Cuando la relación es de muchas ocurrencias a muchas ocurrencias, entonces es M:N “Cardinalidad es la especificación del número de ocurrencias de un (objeto) que puede relacionarse con el número de ocurrencias de otro (objeto)”. Sin embargo, no indica si un objeto particular de datos debe participar o no en la relación. El modelo de datos agrega modalidad al par objeto/relación para especificar esta información. La modalidad de una relación es de 0 si no hay una necesidad explicita para que ocurra la relación o la relación es opcional. La modalidad es 1 si una ocurrencia de la relación es obligatoria.

17. … Conceptos del modelado de datos Clase Automóvil Ejemplos 1 1 1 1 1 1 1 1 4 .. 5 0 ..1 * 2 .. * Clase Asientos ClaseMotor Clase Llantas Clase Techo Corredizo Clase Dados Clase Chasis “Un automóvil se compone de un chasis, un motor, 4 ó 5 llantas, un techo corredizo, cero ó más dados que cuelgan del espejo retrovisor y 2 ó más asientos”

18. 2.4 ANALISIS ORIENTADO A OBJETOS • El objetivo del análisis orientado a objeto (AOO) es definir todas las clases (además de las relaciones y el comportamiento asociado con ellas) relevantes para el problema y que deben resolverse. Esto se logra llevando a cabo algunas tareas: • Deben comunicarse los requisitos básicos del usuario entre el cliente y el ingeniero de software. • Deben identificarse las clases (es decir, se definen los atributos y métodos). • Se define una jerarquía de clases. • Deben representarse las relaciones de objeto a objeto (conexiones entre objetos). • Debe modelarse el comportamiento del objeto. • Las tareas 1 a 5 se vuelven a aplicar de manera iterativa hasta que el modelo esté completo.

19. Conceptos orientados a objetos Atributos: una colección de valores de los datos que describen una clase. Clase: encapsula los datos y las abstracciones de procedimiento requeridos para describir el contenido y el comportamiento de alguna entidad del mundo real. Dicho de otra manera, una clase es una descripción generalizado (por ejemplo, una plantilla un patrón o un plano de trabajo) que describe una colección de objetos similares. Objetos: instancias de una clase específica. Los objetos heredan los atributos y operaciones de una clase. Operaciones: también llamadas métodos servicios proporcionan la representación de uno de los comportamientos de una clase. Subclase: una especialización de la superclase. Una subclase puede heredar tanto los atributos como las operaciones de una superclase. Superclase: también llamada una clase básica, es una generalización de un conjunto de clases que están relacionadas con ella.

20. 2.5 Modelado basado en escenarios La satisfacción del usuario mide el éxito de un sistema. Si los ingenieros de software entienden la manera en que los usuarios finales quieren interactuar con el sistema, el equipo de software será más capaz de caracterizar en forma apropiada los requisitos y construir modelos significativos de análisis y diseño. Por lo tanto, el modelado del análisis con UML comienza con la creación de escenarios en la forma de casos de uso y diagramas de actividad. Casos de uso Un caso de uso captura las interacciones que ocurren entre los productores y consumidores de información y del sistema en sí mismo. Un caso de uso describe un escenario de uso específico en un lenguaje directo desde el punto de vista de un actor definido. El desarrollo de una serie de casos de uso se comienza haciendo una lista de las funciones o actividades que realiza un actor específico. Estas pueden obtenerse de una lista de funciones requeridas del sistema por medio de conversaciones con los clientes o usuarios finales, o mediante una evaluación de los diagramas de actividad desarrollados como parte del modelado del análisis. Un actor no es una persona específica, sino el rol que desempeña una persona (o dispositivo) dentro de un contexto específico.

21. Diagrama de actividad El diagrama de actividad en UML complementaria el caso de uso al proporcionar una representación gráfica del flujo de interacción dentro de un escenario específico. El diagrama de actividad, con carriles, permite al modelador la representación del flujo de actividades descritas por el caso de uso y al mismo tiempo, indicar que actor (si hay múltiples actores involucrados en una función específica) o clase de análisis tiene la responsabilidad de la acción descrita mediante un rectángulo de actividad.

22. 2.5.1 Especificación de Casos de Uso • Preguntas a formular: • ¿Quiénes son los actores y cuáles son sus tareas? • El actor ¿qué información crea, modifica, guarda, lee o destruye? • El actor ¿ qué cambios externos debe notificar al sistema? • El sistema ¿ qué cambios internos debe informar al actor? • Especificación de un CdU: • -Objetivo del CdU: ¿qué debe realizar? • El inicio: ¿cuándo y qué actores lo produce? • El fin: ¿cuándo se produce y qué valor devuelve? • La interacción Actor- CdU: ¿qué mensajes intercambian ambos? • Cronología y origen de las interacciones • Frecuencia del comportamiento: ¿qué operaciones son iteradas? • Escenarios: ¿qué ejecuciones alternativas se presentan en el CdU?

23. Especificación de un Caso de Uso: ejemplo Contenido 1.IDENTIFICACIÓN 2.DESCRIPCIÓN CORTA 3.ACTORES ASOCIADOS 4.FLUJO DE EVENTOS 4.1.Aprobación de Requerimientos. 4.2.Flujo alternativo de eventos 5.PUNTOS DE EXTENSIÓN 6.REQUERIMIENTOS NO FUNCIONALES 7.PRECONDICIONES 8.POSTCONDICIONES 9.CASOS DE USO ASOCIADOS 10.PROTOTIPO DE PANTALLAS Y REPORTES 10.1.Aprobación de Requerimientos 11.ANEXOS Ejemplos

24. Especificación de un Caso de Uso: ejemplo Ejemplos 7. 8. 9. 10.

25. … Diagrama de Casos de Uso • Un caso de uso es un modelo de la interacción entre los usuarios • externos de un SI (actores) y el sistema de información mismo. • Un diagrama de casos de uso es un conjunto de casos de uso. • Interacción entre Casos de Uso: • Inclusión.- son incorporadas en otro CdU y pueden ser compartidas por varios CdU. No pueden ser ejecutados directamente por un actor. • Regla para su aplicación: cuando se “usa siempre” Devolución a proveedor <<inclusión>> Actualizar Stock <<inclusión>> Actor Salidas a fábrica

26. Interacción entre Casos de Uso: • Extensión.- son transacciones relevantes que forman CdUs y que son diferentes secuencias o alternativas de un CdU. Si pueden ser ejecutados directamente por los actores. • Regla para su aplicación: cuando se “usa a veces” La flecha siempre señala al CdU que está siendo incluido o extendido <<extensión>> Pagar en efectivo <<extensión>> Pagar cuotas Pagar con cheque Cliente <<extensión>> Pagar con tarjeta de crédito

27. Diagrama de Casos de Uso: ejemplo Ejemplos SAR- Sistema de administración de requerimientos

28. 2.5.2 Diagramas de actividad Un diagrama de actividad modela la secuencia de actividades que se desarrollan en el flujo de trabajo de un Caso de Uso. También podemos modelar el flujo de un objeto cuando pasa de un estado a otro en diferentes puntos de control del flujo. A diferencia de los diagramas de interacción que destaca el flujo de control entre objetos, un diagrama de actividad destaca el flujo de control entre actividades. Ejemplos

29. Un diagrama de actividad para una Cia. ensambladora de PCs Ejemplos

30. Práctica: Diagrama de actividad con carriles Proceso de negocio: Un cliente hace un pedido; el pedido es enviado al Departamento de Ventas para ser procesado. Una vez procesado, es enviado al Almacén para preparar y enviar el pedido al cliente. Ventas elabora la factura. El cliente recibe el pedido, paga la factura, y Ventas determina que el pedido ya ha sido atendido.

31. … Diagrama de actividad

32. FIN DE LA SESION 2