1

ESCUELA ACADEMICO PROFESIONAL DE

INGENIERIA DE SISTEMAS

PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

Curso : Ingeniería de Software

Sesión 2 :

2 EAP INGENIERIA DE SISTEMAS Curso Ingeniería de Software

Temario ...

Fases y modelos.

Modelo del Negocio.

Diagrama de actividades del negocio.

Casos de uso del negocio.

Modelos de objetos del negocio.

PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

Sesión 2 :

3

Fases y modelos ...

4 EAP INGENIERIA DE SISTEMAS Curso Ingeniería de Software

El Proceso UnificadoUn proceso de software “guiado por 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, focalizando las metas correctas, como el entendimiento, el ajuste a los cambios futuros y la reutilizacion”

Plantea un flujo de proceso iterativo e incremental, concordando con la caracteristica evolutiva del software moderno.

5 EAP INGENIERIA DE SISTEMAS Curso Ingeniería de Software

Fases del Proceso Unificado

Fig. Relación del Proceso Unificado con la actividades genéricas

del marco de trabajo del proceso de software

Lanzamiento

6

Fases del Proceso Unificado

INICIO Comprende la comunicación con el cliente y las actividades 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 requisitos fundamentales del negocio se describen a través de un conjunto preliminar de Casos de Uso (CdU).Los CdU describen las características y funciones deseables para cada clase importante de usuarios.

ELABORACIONSe 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. Expande la representacion arquitectónica para incluir 5 visiones diferentes 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 Proceso Unificado

CONSTRUCCIONDesarrolla o adquiere los componentes del software que hara que cada CdU sea operativo para los usuarios finales.Se diseñan y ejecutan pruebas de unidad para cada componente. Se realizan las actividades 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 esta fase, 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

Descripción del sistema

Modelo de Análisis

Modelo de Diseño

Funcionalidad general del sistema

(aplicando SW, HW,Datos, Humanos)

Y, otros elementos del sistema

(Ejm: seguridad, rendimiento)

Arquitectura de aplicación del SW

Interfaz con el usuario

Estructura en el nivel de componentes

(llena el vacío entre una descripción al nivel de sistemas y

el diseño de software)

Fig. El modelo de análisis como un puente entre la descripción del sistema y el modelo de diseño

11

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.

2.2 Enfoques del modelado de analisis

12

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

2.3 Conceptos del modelado de datos

13

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.

Marca Modelo Nro. de Id. Tipo Color PropietarioBMW 25XPT F214 Coupé Crema JCRToyota Aris MD256 Sedan Granate WCBFord Leopard 25CB32 Deportivo Amarillo JBPorche Avanz R55B2 Coupé Azul LCB

Instancia

Nombres de atributos

Atributos descriptivosAtributos

referencialesIdentificador

Une los objetos de datos entre si

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.

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

persona

automóvil

automóvil

a) Una conexión básica entre objetos de datos

b) Relaciones entre objetos de datos

posee

autorizada para manejar

16

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: 1Y, si es con muchos objetos entonces la relación es 1:NCuando 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.

… Conceptos del modelado de datos

17

… Conceptos del modelado de datos

Ejemplos Clase Automóvil

Clase Motor Clase Llantas Clase Techo Corredizo

Clase Dados

1 1 1 1 1 1

1 1 4 .. 5 0 ..1 * 2 .. *

“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”

Clase Chasis Clase 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:

1. Deben comunicarse los requisitos básicos del usuario entre el cliente y el ingeniero de software.

2. Deben identificarse las clases (es decir, se definen los atributos y métodos).

3. Se define una jerarquía de clases.4. Deben representarse las relaciones de objeto a objeto

(conexiones entre objetos).5. Debe modelarse el comportamiento del objeto.6. Las tareas 1 a 5 se vuelven a aplicar de manera iterativa hasta

que el modelo esté completo.

19

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.

Conceptos orientados a objetos

20

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

2.5 Modelado basado en escenarios

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ÓN2. DESCRIPCIÓN CORTA3. ACTORES ASOCIADOS4. FLUJO DE EVENTOS4.1. Aprobación de Requerimientos.4.2. Flujo alternativo de eventos5. PUNTOS DE EXTENSIÓN6. REQUERIMIENTOS NO FUNCIONALES7. PRECONDICIONES8. POSTCONDICIONES9. CASOS DE USO ASOCIADOS10. PROTOTIPO DE PANTALLAS Y REPORTES10.1. Aprobación de Requerimientos11. ANEXOS

Ejemplos

24

Especificación de un Caso de Uso: ejemplo

7.

8.

9.

10.

Ejemplos

25

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”

… Diagrama de Casos de Uso

Devolución a proveedor

Salidas a fábrica

Actualizar Stock

Actor

<<inclusión>>

<<inclusión>>

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”

Pagar en efectivo

Cliente

<<extensión>>

Pagar cuotas Pagar con cheque

Pagar con tarjeta de crédito

<<extensión>>

<<extensión>>

La flecha siempre señala al CdU que está siendo incluido o extendido

27

Diagrama de Casos de Uso: ejemplo

SAR- Sistema de administración de requerimientos

Ejemplos

28

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.

2.5.2 Diagramas de actividad

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 EAP INGENIERIA DE SISTEMAS Curso Ingeniería de Software

FIN DE LA SESION 2