uml 2.5 requisitos

7/29/2019 UML 2.5 Requisitos

1/59

Ing: Carlos Daz Snchez

IDAT


2/59

Captulo 4:Requisitos

Temas:1.

2.

Disciplina RUP de Requisitos

ModeladodeCasosdeUso

IDAT


3/59

Requisitos

DisciplinaRUPdeRequisitos1.

IDAT


4/59

REQUISITOS

1.Disciplina RUP de Requisitos

1.1

1.21.3

Introduccin

RUP. Workflow del procesoActividadesdelWorkflow

IDAT


5/59

1.1. INTRODUCCIN

Un requerimiento es consideradouna

condicin oajustar

capacidad a la que se debeel sistema quedesarrollando

seest

IDAT


6/59

1.1. INTRODUCCINFinalidad:

Establecer y mantener un acuerdo con los clientes y otrosinteresados, acerca de lo que debe hacer el sistema.Proporcionar desarrolladores de sistema con un buenconocimiento de los requisitos del sistema.

Definir los lmites del sistema (delimitarlo).

Proporcionar una base parade las iteraciones.Proporcionar una base paratiempo en que desarrollar el

planificar el contenido tcnico

la estimacin del coste y delsistema.

Definir una interfaz de usuario para el sistema,centrndose en las necesidades y los objetivos de losusuarios.

IDAT1. Disciplina RUP de Requisitos


7/59IDAT1. Disciplina RUP de Requisitos

1.2. DISCIPLINA RUP: REQUIREMENTS


8/59

s

REQUISITOSEl Analista de Sistemas

El Arquitecto de software

El

El

Especificador deRequisito

revisortcnico

IDAT1.2. Disciplina RUP: Requirements

1.2.1. ROLES EN EL MODELADO DE


9/59IDAT1.2. Disciplina RUP: Requirements

1.2.2. WORKFLOW



1.2.3. PRODUCTOS DE TRABAJO / ARTEFACTOS



MAPEO ENTRE MODELOS


12/59

Analizar el problema.

Conocer las necesidadesde los stakeholders.

Definir el sistema.

Gestionar el mbito del

sistema.Perfeccionar la definicindel sistema.

Gestionar cambiosrequisitos.

de

IDAT1. Disciplina RUP de Requisitos

1.3. ACTIVIDADES DEL WORKFLOW


13/59

Business Analysis ModelBusiness Use Case Model

REQUERIMIENTOS

StakeholdersRequestBusiness Rules

IDAT1.3. Actividades del Workflow

1.3.1. IDENTIFICAR REQUERIMIENTOS


14/59

Tcnicas de capturarequerimientos: de

Entrevistas.Cuestionarios.

Encuestas.Descripcin de puestos.

Artefactos del Modelado

Negocio.Revisar los documentosactuales.

de


1.3.1. IDENTIFICAR REQUERIMIENTOS


15/59

REQUERIMIENTOS

FUNCIONALES NOFUNCIONALES


Tambin estn los pseudo_requerimientos, queson aquellos requerimientos impuestos por elcliente que restringen la implementacin del

sistema.

1.3.2. TIPOS DE REQUERIMIENTOS


16/59

Requerimientos FuncionalesSon los requerimientos del usuario que el

sistemaindicando

a desarrollar, debe satisfacer,cules son las condiciones de

entrada (inputs) y las condiciones de salida(outputs).

Requerimientos No FuncionalesSon caractersticas que el sistema debetener para poder asegurar la calidad del

sistema.


1.3.2. TIPOS DE REQUERIMIENTOS


17/59

Definicin:Especifican las condiciones que deben sercumplidas por el sistema.

Se identifican desde el punto de vistacliente. del

SeSe

redactan en lenguaje natural. capturan en dos

Especificacin deSoftware.Modelo de Casos

artefactos.

Requerimientos de

de Uso de Sistema.

IDAT1.3.2. Tipos de requerimientos

A. REQUERIMIENTOS FUNCIONALES


18/59

Asociados a los casos de uso del sistemaEjemplo:

El sistema debe actualizar la informacin de losprofesores que dictan los cursos de baile.

El sistema permitir registrar los horarios dedictado de clase definidas por el administrador.

Se podr Consultar la programacin del rollos campeonatos locales y regionales.

El sistema debe permitirCerrar un curso.

de




19/59

Asociados a otros aspectos generales.Ejemplo:

El sistema debe obligar al usuario a cambiar

su contrasea cada 60 das.Se debe incluir un mecanismo que permitasu actualizacin automtica sin laintervencin del usuario.

Deber contener un registro de los errores ypara cada uno, debe registrar: el cdigo delerror, una descripcin del error, la fecha y lahora del error.




20/59IDAT1.3.2. Tipos de requerimientos

REQUERIMIENTOSEXTERNOS

DED REQUERIMIENTOSLEGALES REQUERIMIENTOSETICOS

DE ESTNDARES

REQUERIMIENTOSDE PRIVACIDAD

REQUERIMIENTOSDE SEGURIDAD

REQUERIMIENTOSDEL PRODUCTO

REQUERIMIENTOSDE USABILIDAD REQUERIMIENTOSDE EFICIENCIA REQUERIMIENTODE FIABILIDAD

REQUERIMIENTOSDE DESEMPEO

REQUERIMIENTOSDE ESPACIO

REQUERIMIENTOSNO FUNCIONALES

REQUERIMIENTOSORGANIZACIONALES

S REQUERIMIENTOSDE PORTABILIDAD REQUERIMIENTOSINTEROPERABILIDA

REQUERIMIENTOSDE ENTREGA

REQUERIMIENTOSDE

IMPLEMENTACION

REQUERIMIENTOS

B. REQUERIMIENTOS NO FUNCIONALES


21/59

Algunas de las categoras:Usabilidad: Fcil uso, esttica y estndarde la interfaz, documentacin de usuario,materiales de capacitacin.Fiabilidad: Exactitud en los clculos delsistema, seguridad contra fallas, capacidadde recuperacin y/o correccin de erroresdel usuario, prediccin de resultado antes

de ejecutar la operacin.Eficiencia: Rapidez, tiempo de espera,demora en clculos, capacidad de memoria.




22/59

Usability (Usabilidad Facilidad de uso)

Ejemplo.

El lenguaje empleado en la interfaz grfica del sistemadebe respetar los trminos usados en el negocio.

El sistema permitir a losusuariosrealizarbsquedassinentrenamientoprevio.

IDAT1.3.2. Tipos de Requerimientos



23/59

Reliability (Confiabilidad o Fiabilidad)

Ejemplo.

El sistema debe estar disponible 24x7x365 das al ao.

El sistema estar disponibleal95porcientoentrelas8:00 AMylas6:00PM




24/59

Performance. (Rendimiento)

Ejemplo:

El sistema debe permitir al administrador registrar unamatrcula como promedio en 30 segundos.

Durante el proceso de matrcula, el sistema permitir elacceso concurrente de 500 alumnos.

El sistema permitir almacenar la informacin de hasta4000 alumnos.

El 95 por ciento de las transacciones del sistema nodeben exceder los 5 segundos




25/59

Supportability (Soporte)

Ejemplo.

El cliente Web del sistema debe soportar los siguientesnavegadores:

Microsoft Internet Explorer 7.0 o superior FireFox 1.5 o superior para Linux y para

Windows

El sistema debe ser compatible con Windows 2003

profesional y Windows XP.El sistema debe permitir a un usuario su instalacin sinentrenamiento previo.




26/59

Requisitos

2.ModeladodeCasosdeUso

IDAT


27/59

REQUISITOS

2.Modelado de Casos de Uso

2.1

2.22.3

2.4

Elementos

Diagrama de Casos de UsoEstructura del diagrama

DocumentacindelosCasosdeUso

IDATDivisin de Alta Tecnologa - DAT


28/59

2.1. ELEMENTOS

IDAT2. Modelado de Casos de Uso

ELEMENTO NOTACIN UML

Actor

Casos de Uso


29/59

El actor representa un ROL, noes un usuario individual delsistema.

Un actor es cualquier cosa queintercambia datos con el sistema.

Un actor puede ser un usuario,

hardwareexternouotrosistema

IDAT2.1. Elementos

2.1.1. ACTOR


30/59

Los actores se determinan observando:Usuarios directos del sistema.Trabajadores y/o Actores del Negocio.

Responsables del uso o mantenimientosistema.

del

Otros sistemas que interactansistema.

con el

El nombre del actor describedesempeado.

el papel

IDAT2.1. Elementos


31/59

Preguntas para ayudar a identificar mas actores:

Quin

Quin

Quin

Quin

usar la funcionabilidad principal del sistema?

est interesado en cierto requerimiento? se

beneficia con el uso del sistema? administrar,

soportar y mantendr el sistema?

El sistema usa un recurso externo?

Alguna persona juega varios roles diferentes?

El sistema interacta con otro sistema?

IDAT2.1. Elementos

2.1.1. ACTOR


32/59

Sugerencias para identificar actores delsistema:

Son roles (humanos, software o hardware), no personascon nombres propios.No siempre estn asociado con el nombre de un cargo enla planilla de la organizacin objetivo.El nombre no debe representar reas, departamentos o

partes de una organizacin sino roles de ejecucin.Cada actor debe estar asociado con al menos, un caso deuso del sistema; caso contrario, debe ser eliminado delmodelo.

IDAT2.1. Elementos

2.1.1. ACTOR

1 2 CASO DE USO


33/59

.1.2. CASO DE USO

Un caso de uso es un procesoespecfico del sistema conidentidad propia que define unasecuencia de acciones que elsistema realiza para un actor en

particular.Los casos de uso recopilados

constituyenposibles de

todos losutilizar el

modossistema.

IDAT2.1. Elementos

2 1 2 CASO DE USO


34/59

Realizacin de Casosde Uso de Negocio

Mapeo para obtener Casosde Uso (sistema)

IDAT2.1. Elementos

2.1.2. CASO DE USO

2 1 2 CASO DE USO


35/59

Cada Caso de uso debe tener unnombre que indique lo que se haconseguido por medio de sus

interacciones con losDos casos de uso nomismo nombre.Nombre:

actores.puedentenerel

Registrar

Cliente

verbo + objeto afectado

IDAT2.1. Elementos

2.1.2. CASO DE USO


36/59

El proceso va relacionado con la identificacin deactores.

Por cada actor identificado se podr preguntar:

Cules son las tareas automatizables del actor?

Qu informacin crea, guarda, modifica, destruyelee?

El actor debe notificar al sistema los cambiosexternos?

El sistema debe informar al actor los cambiosinternos?

o

IDAT2.1. Elementos

2.1.2. CASO DE USO


37/59

Caso de Uso Vs. Requerimiento

Funcional.

Existe una correspondencia directa entreambos.La diferencia radica en la manera en quedescriben la necesidad de funcionalidad.

Los RF se describen desde la perspectiva delusuario o cliente del proyecto.

Los CUS se describen desde lade la arquitectura del sistema.

perspectiva

IDAT2.1. Elementos

2.1.2. CASO DE USO


38/59

Los diagramas conactores, casos deuso y relacionesentre ellos sedenominandiagramas decasos de uso eilustran las

relaciones en elmodelo de casosde uso.

Cajero


uc Atencion al publico

Registrar Retiro

Consultar Tipo deCambio

Registrar Deposito

2.2. DIAGRAMA DE CASOS DE USO

2 2 DIAGRAMA DE CASOS DE USO


39/59

Representa lo que hace el sistema y surelacin con el entorno, desde el puntode vista del usuario.

Son iniciados por un agente externo: ElActor.Describen lo que hace el actor y lo que haceel sistema al interactuar.Estn limitados a una sola tarea.

Muestra grficamente los requerimientosfuncionales del sistema.


2.2 DIAGRAMA DE CASOS DE USO

2 2 DIAGRAMA DE CASOS DE USO


40/59

Se tiene en cuenta QUIN realizaQU actividad?

QUIN? (actor del sistema identificado).QU? (caso de uso identificado).Relaciones entre ellos (asociaciones).

No constituye un Diagrama de Flujode Datos.


2.2 DIAGRAMA DE CASOS DE USO

2 2 2 ASOCIACIN


41/59

Caractersticas:

una relacin de asociacin.

Los actores se conectan a los casos de uso, a travs de

Esta relacin se estereotipacomocomunicatespero

noesnecesarioindicarla.

IDAT2.2 DIAGRAMA DE CASOS DE USO

Uc Casos de Uso

Caso de uso

Actor

2.2.2. ASOCIACIN


42/59

Se estructura el modelo de casos de uso para que losrequisitos sean ms fciles de entender y mantener. Esto

incluye promover la similitud entre los casos de uso yopcionallosyactores e identificar el comportamientoexcepcional.


2.3. ESTRUCTURA DEL DIAGRAMA


43/59

Objetivos:Encontrar comportamiento similar o comnen el Modelo de Casos de Uso del Sistema.

Identificar actividades bsicas o alternasque se repitan en los casos de uso.

Identificar actores queejecutados por otros.

compartenroles


2.3. ESTRUCTURA DEL DIAGRAMA


44/59

.3.1. RELACIN INCLUDEEs una relacin dedependenciaentre

doscasosdeuso.

IDAT2.3. Estructura del diagrama 2 3 1 RELACIN INCLUDE


45/59

Caractersticas:

Se establece cuando el caso de uso base necesita incluirobligatoriamente la secuencia de acciones descritas porel caso de uso incluido.

Indica que el comportamiento del caso de uso incluidoest explcitamente insertado dentro del comportamiento

definido por el caso de uso base.El caso de uso base es el que conoce la asociacin entre

ambos y el caso de uso incluido, nocules casos de uso lo incluyen.

Se utiliza el estereotipo include .

necesitaconocer

IDAT2.3. Estructura del diagrama

2.3.1. RELACIN INCLUDE


46/59

En el proceso de abastecimiento de una empresa, se cuentacon dos casos de uso que comparten una funcin comn:

actualizar el stock de productos sumandoorestandoelmovimientoefectuado.

Includerecepcion de productos


Registrar

Actualizar Stock

Include

Almacenero Despachar productos


2 3 1 RELACIN INCLUDE


47/59

En la documentacin:Flujo Bsico

1.2.

...6.

...

...

El sistema actualiza el stock de cada

producto. Incluir el casostock del producto.

deusoActualizar



NO ES INCLUDE !!!


48/59

includeAadir Libro

Mantener Libros

include

Eliminar Libroinclude

includeAadir Peticion

includeGestionar

Biblioteca

Mantener Peticiones

include

Eliminar Peticion

includeBibliotecario

includePrestar Libro

Mantener Prestamos include

Devolver Libro


NO ES INCLUDE !!!

2 3 2 RELACIN EXTEND


49/59

Es unaciertas

relacin que secondiciones.

ejecuta bajo

Devolver ejemplar

Fecha retrasada

extends

Aplicar Mora


2.3.2. RELACIN EXTEND


50/59

Es una relacin de dependencia entre dos casos deuso.

Se establece cuando el caso de uso extendido ocurreexcepcionalmente en el caso de uso base.

El caso de uso extendido ocurre slo cuando ocurra elevento respectivo dentro del caso de uso base.

Indica que el comportamiento del caso de uso

extendido puede ser insertado en el comportamientodefinido por el caso de uso base.



2 3 2 RELACIN EXTEND EJEMPLO


51/59

El Caso de Uso Registrar venta

en un supermercado, tiene unafuncin adicional si el clientepresenta su tarjeta deacumulacin de puntos.

Las acciones para Actualizarpuntosslo se presentan si elcliente tiene la tarjeta enmencin y deben separarse enun caso de uso independiente.

Registrar Venta

Si presenta tarjeta

extends

vendedor

Actualizar puntos


2.3.2. RELACIN EXTEND - EJEMPLO

2 3 2 RELACIN EXTEND


52/59

Documentacin.Flujo Alternativo.

1. ...

2. ........

8. Si el cliente posee

Tarjeta de acumulacinde puntos, entonces se actualizan sus puntos.

Extenderel caso de uso Actualizar puntos.

IDAT

2.3. Estructura del diagrama


2 3 3 ASOCIACIN DE TIPO GENERALIZACIN


53/59

La generalizacin de casos de uso se utiliza cuando tieneuno o ms casos de uso, que son realmente

especificacionesouncasomsgeneral.

Validar Usuario

inheritsinherits

Validar conpassword Examinar Retina


2.3.3. ASOCIACIN DE TIPO GENERALIZACIN



54/59

Es una relacin de herencia entre casosuso.

Los casos de uso hijos heredan laestructura, comportamiento yasociaciones del caso de uso padre.

El caso de uso padre es abstracto y

slo se crean instancias de los casosuso hijos.

de




55/59

EJEMPLORegistrar una orden de

pedido.Registrar pedido portelfono y Registrar pedidopor Internet tienen accionesiguales que pueden

generalizarse en RegistrarPedido.

Los hijos heredan la

Registrar Pedido

Registrar pedido telefonico Registrar Pedido por Internet

estructura, comportamientoasociaciones del padre.

y

OperadorCliente de Internet




56/59

Cundo utilizar la generalizacin?

Cuando existen dos o ms casos de usoque poseen un comportamiento y estructura

muy comn.

Las actividades comunes son llevadas haciaun caso de uso padre o generalizado.

Las actividades diferentes y particulares sequedan en los casos de uso hijos.



3 4 GENERALIZACIN ENTRE ACTORES


57/59

.3.4.GENERALIZACIN ENTRE ACTORES

El actor hijo hereda el rol representadoporelactor padre enlarelacin.

P a d r e

inhe r i t s

IDATHijo2.3. Estructura del diagrama

3 4 GENERALIZACIN ENTRE ACTORES


58/59

.3.4.GENERALIZACIN ENTRE ACTORES

La asociacin de tipo Generalizacinentre actores se da cuando:

Si existen dos o ms actores que:

Interactan o utilizan el sistema de la mismaforma.

Juegan el mismo rol frente al sistema.

Entonces es posible.

Establecer una relacin de Generalizacinellos.

Simplificar el modelo de Casos de Uso.

entre



59/59

EJEMPLO

includeIncidencias

Actualizar TarjetaSupervisor

IDAT

uc Comercializacion

Comprar productosinclude

Comprador Actualizar Stock

Registrar

Vender productosinherits

Si tiene Tarjeta

extends

Vendedor

Bonus

uml 2.5 requisitos

Documents