UNIDAD II. Vista Arquitectural Funcional

CURSO AMD-IS 4.
0
DISEÑO DE APLICACIONES
EMPRESARIALES USANDO
UML 2.5.1
UNIDAD N° 2. VISTA
ARQUITECTURAL FUNCIONAL
Prof. Msc. Ana Mercedes Díaz - UCLA
Unidad II. Vista Arquitectural Funcional
 Objetivos de la Unidad II
 Definirtodos los pasos que se deben seguir para
ejecutar el proceso de generación de la Vista
Arquitectural Funcional
 Construir todos los artefactos de la Vista Arquitectural
Funcional.
 Conocer los elementos que conforman el Diagrama de
Casos de Uso
Curso AMD-IS 4.0. Diseño de Aplicaciones Empresariales Usando UML 2.5.1 - UCLA
Estructura de la Unidad II
 Definición del Modelo Funcional
 Diagrama de Casos de Uso
 Elementos del Diagrama
 Especificación de los Casos de Uso (Plantilla)
 Elementos de la Plantilla
 Matriz de Trazabilidad entre requisitos
funcionales y casos de uso
 Ejemplos
Definición del Modelo Funcional
 El Modelo Funcional de la Solución nos permite ver
de una manera gráfica y literal los requisitos o las
funciones que debe exhibir la solución propuesta
utilizando TIC.
 El Modelo Funcional esta constituido por:
 El Diagrama de Casos de Uso
 Especificación de cada caso de uso
 Matriz de trazabilidad entre requisitos funcionales y casos

de uso
 Diagrama de Casos de Uso
Diagrama de Casos de Uso
 El Diagrama de Casos de Uso muestra las funciones
que tendrá el sistema o aplicación a desarrollar.
 El Diagrama de Casos de Uso mostrará un conjunto
de casos de uso asociados a un(os) actores
Diagrama de Casos de Uso
 El Diagrama de Casos de Uso tiene unos elementos
(Actor, casos de uso) y un conjunto de relaciones
(entre actor y casos de uso y entre casos de uso)
Elementos: Caso de Uso
 Un Caso de Uso, representa una funcionalidad o
función del sistema, en otras palabras puede
representar un requisito funcional de la aplicación.
 De manera externa representa un función.
 De manera interna el Caso de Uso representa un
conjunto de pasos o acciones que conducen al logro
de un objetivo
 Gráficamente el Caso de Uso se representa de la
siguiente manera:
Tomado de la Tabla 16.1 de la Especificación de UML 2.5.1
 Con la herramienta Visual Paradigm que usaremos
se verá de la siguiente manera
 Estándares para la escritura de los casos de uso:
 El nombre del caso de uso lo colocaremos dentro del
Caso de Uso.
 El nombre del caso de uso debe comenzar con un
verbo que indique acción más un complemento.
Ejemplo: Registrar paciente
Elementos: Actor
 El Actor, representa algo o alguien que esta fuera
del sistema y que acciona o interactúa con
alguna(s) funcion(es) de la aplicación.
 El Actor puede ser una persona, otro sistema, una
base de datos, etc.
Elementos: Actor
 Gráficamente el Actor se puede representar de la
siguiente manera:
Tomado de la Tabla 16.1 de la Especificación de UML 2.4.1
Elementos: Actor
 Con la herramienta Visual Paradigm que usaremos
se verá de la siguiente manera:
Elementos: Actor
 El nombre del Actor siempre será escrito en singular
y la primera letra en mayúscula y el resto en
minúscula. Ejemplo: Paciente
Relaciones: Asociación
 La relación de Asociación es una relación que
asocia a un actor con un caso de uso y significa que
el actor activa o participa en ese caso de uso.
Relaciones: Asociación
Relaciones: Extend e Include
 El Extend y el Include son relaciones de
dependencias, es decir, dependen de que el
caso de uso base se ejecute para poder
ejecutarse el caso de uso extendido o incluido.
 Por lo general estas relaciones surgen de un
proceso de refinamiento del diagrama de
casos de uso.
 El Caso de Uso incluido es de ejecución
obligatoria y el extendido es de ejecución
condicionada
 Un Caso de Uso incluido por lo general es un
comportamiento que será usado por dos o más
casos de uso base.
 Es un comportamiento común a dos o más casos de
uso, lo que conduce a que el diseño exhiba
elementos altamente reusables.
Como se diagraman las relaciones entre casos de uso:
Ejemplo de una situación cotidiana
Ejemplo de una situación cotidiana
Elemento opcional: Borde del Sistema
 Especificación de los Casos de Uso
Especificación de los Casos de Uso
(Plantilla)
 Es un documento que se construye por cada caso de
uso, y en él se especifica todo lo relacionado con
las acciones que ocurren paso a paso y en orden
lógico para que se ejecute ese caso de uso.
 Se construye a través de una plantilla.
Especificación de los Casos de Uso
(Plantilla)
Nombre
Descripción
Actor(es)
Tipo
Curso Normal Acción del Actor Acción del Sistema
1. Esta use case se inicia……

cuando … n. Fin de la Use Case
Curso Alterno
Pre-condición
Post-condición
Pasos para construir el Diagrama de
Casos de Uso y la Plantilla
1. Haber entendido el negocio (Modelado del
Negocio).
2. Listar los requisitos funcionales (funcionalidad del
software = parte de la solución propuesta)
3. Si es posible, realice la taxonomía de los Rq
funcionales.
4. Modelar por cada Rq un caso de uso (Tenga presente
comenzar con los Rq medulares de la aplicación). No
olvide el alcance de la aplicación.
Nota: El diagrama de casos de uso no admite
secuencialidad, ni descomposición funcional. Si fuera
necesario algún tipo de agrupamiento utilice el
diagrama de paquetes de UML 2.1.
5. Si observa alguna relación de include o extend
(evidente modelarla en el diagrama).
Pasos para construir el Diagrama de
Casos de Uso y la Plantilla
6. Hacer un análisis semántico de cada caso de uso, esto
implica hacer la descripción literal es decir el llenado
de la plantilla del caso de uso.
7. Con esta descripción revisar el alcance del caso de
uso, y determinar si se puede crear un(os) include o
un(os) extend
Nota: Tener presente dos conceptos muy importantes en
diseño de software (cohesión y el acoplamiento)
8. Refinar el diagrama de casos de uso, conjuntamente
con las plantillas (Recuerde que debe existir
CONSISTENCIA en ambos documentos)
9. Seguir refinando hasta obtener la línea base del
Modelo de Casos de Uso.
 Matriz de Trazabilidad entre Requisitos
Funcionales y Casos de Uso
Matriz de Trazabilidad
 Es una matriz que se genera entre la
Especificación de los Requisitos funcionales y
los Casos de Uso.
 Su objetivo es garantizar que todos los
requisitos estén incluidos en el Diagrama de
Casos de Uso.
 La correspondencia no es necesariamente de 1
a 1. Es decir, un requisito pudiera estar
contenido en uno o más casos de uso.
Matriz de Trazabilidad
CU1 CU2 CU3 CU4 CU5 CU6
Rq1 x
Rq2 x
Rq3 x
Rq4 x
Rq5 x
Rq6 x
Rq7 x
 Ejemplos de Diagrama de Casos de
Uso
Ejemplo N° 1
Validar Usuario
<<includes >>
Us uario
<<includes >> Mostrar Cont enido
Cliente Em pleado Regist rar U suario

<<includes >>
Generar Repot e
<<ext ends>>
Mostrar es tado de la
<<ext ends>>
solicitud de soporte
<<ext ends>>
<<ext ends>>
Mostrar Solic itudes
de s oporte
Proces ar Solicit ud de <<ext ends>>

Soporte Técnic o Cargar Inf orm ac ión
<<ext ends>> General
<<ext ends>>
<<ext ends>>
Mostrar I nf ormación
<<ext ends>> general del cliente
Introducir/ m odif ic ar
nuev a Soluc ión
Mostrar I nf ormación
Proces ar Solicit ud de técnic a del cliente
Elim inar Solución
Inf orm ación de s oluc ión
Ejemplo N° 1
 El ejercicio anterior resume mucho de lo que NO se
debe hacer en un Diagrama de Casos de Uso,
porque penaliza enormemente la cohesión y el
acoplamiento.
 El siguiente ejemplo muestra las operaciones que
debe realizar un telecajero, desde la perspectiva
del cliente.
Ejemplo N° 2
 Requisitos para el Telecajero:
 Que el cliente pueda:
 Hacer transferencias.
 Retirar Dinero
 Consultar dinero
 Depositar dinero
 Cambiar su clave.
Ejemplo N° 2
Ejemplo N° 2
Ejemplo N° 2
 El refinamiento anterior es incorrecto porque
penaliza la cohesión de la solución.
 El siguiente refinamiento si es una solución
mucho más acertada, recuerden que no se
debe aprobar el 100% hasta tanto no
tengamos descritas las plantillas de todos los
casos de uso participantes, con las cuales
confirmemos la consistencia de todo el modelo
de Casos de Uso.
Ejemplo N° 2
Ejemplo N° 3
 En el siguiente ejemplo podemos observar un
Diagrama de casos de uso y la matriz de
trazabilidad, modelado utilizando la HDS
Enterprise Architect.
Ejemplo N° 3
EA 7.5 Unregistered Trial Version
uc Manage Users EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Versi
The following diagram illus trates the Us e
EA 7.5
Cas Unregistered
es relating to ManagingTrial
Us ers .Version
Som e of EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Versi
the us e cas es contain nes ted Sequence and
Com
EA 7.5m unication diagram s . You
Unregistered canVersion
Trial double- EA Login
7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Versi
click thes e us e cas es to view the child
diagram s
EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Versi
View History
EA 7.5 Unregistered Trial Version EA 7.5
Create Unregistered Trial Version
Account EA 7.5 Unregistered Trial Versi
EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version

«extend»
EA 7.5 Unregistered Trial Versi
Client
View Account details View Open Orders
(from Actors) «extend»Trial Version
EA 7.5 Unregistered Trial Version EA 7.5 Unregistered EA 7.5 Unregistered Trial Versi
Close Account
«include»
EA 7.5 Unregistered Trial Version EA 7.5User

Delete Unregistered Trial Version EA 7.5 Unregistered Trial Versi
EA 7.5 Unregistered Trial Version

Administrator EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Versi
(from Actors)
Ejemplo N° 3
Resumen
 En Resumen el Modelo Funcional de la Solución
debe contener los siguientes elementos:
 Diagrama de Casos de Uso
 Plantillas de cada caso de uso.
 Matriz de Trazabilidad entre requisitos y casos de uso.
Resumen
 Recomendaciones para escribir Casos de Uso:
 Mantenga los casos de uso breves y sencillos.
 Céntrese en el qué, y no en el cómo.
 Evite descomposición funcional.
 ¿PREGUNTAS?
Bibliografía
 www.omg.org.
 “El Proceso Unificado de Desarrollo de Software” . I.

Jacobson, G. Booch y J.Rumbaugh. Addison Wesley -
Pearson Education 1999
 “UML Lenguaje de Modelado Unificado” . I. Jacobson, G. Booch y

J.Rumbaugh. Addison Wesley - Pearson Education 1999
 “UML Lenguaje de Modelado Unificado 2.0” . I. Jacobson, G. Booch y

J.Rumbaugh. Addison Wesley - Pearson Education 2009
 Fin de la Unidad II

UNIDAD II. Vista Arquitectural Funcional

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

UNIDAD II. Vista Arquitectural Funcional

Enviado por

Direitos autorais:

Formatos disponíveis

CURSO AMD-IS 4.

 Matriz de trazabilidad entre requisitos funcionales y casos

Tomado de la Tabla 16.1 de la Especificación de UML 2.5.1

Tomado de la Tabla 16.1 de la Especificación de UML 2.4.1

Como se diagraman las relaciones entre casos de uso:

Curso Normal Acción del Actor Acción del Sistema

1. Esta use case se inicia……

<<includes >> Mostrar Cont enido

Cliente Em pleado Regist rar U suario

Proces ar Solicit ud de <<ext ends>>

EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version

EA 7.5 Unregistered Trial Version EA 7.5User

EA 7.5 Unregistered Trial Version

 Matriz de Trazabilidad entre requisitos y casos de uso.

 Evite descomposición funcional.

 “El Proceso Unificado de Desarrollo de Software” . I.

 “UML Lenguaje de Modelado Unificado” . I. Jacobson, G. Booch y

 “UML Lenguaje de Modelado Unificado 2.0” . I. Jacobson, G. Booch y

Você também pode gostar