s02E42020-1

Seminario de Proceso Unificado
de Desarrollo – Introducción
General
Presentación
Rodrigo Cerón
Popayán, agosto de 2020
Universidad del Cauca
Departamento de Telemática

Contenido
 Antecedentes
 Objetivos
 Características
 Organización
 Por Componentes
 En el tiempo
 Componentes y Modelos
Énfasis en Ingeniería Telemática 231/08/2020

Antecedentes
 Desarrollado originalmente por Jacobson
Centrado alrededor de Casos de Uso
Orientado a Objetos: Objectory
+ Rational Approach: Kruchten, Booch, Royce
Proceso iterativo
Centrado en la arquitectura del software
+ Metodología OMT propuesta por Rumbaugh
+ SQA Process: Metodología de pruebas
+ Requirements College: Gestión de requisitos

Objetivos
 Proceso de ingeniería de software que
busca
 Asegurar la producción de software de alta
calidad
 Satisfaciendo las necesidades del cliente
 Con un plan y presupuesto predecibles

Modelo de Desarrollo en Espiral
0
Objetivos,
Alternativas,
Restricciones
1
Evaluación de
Alternativas,
Ident. y
Resol. de
Riesgos
23
Desarrollo del
Producto
Planeación
Siguiente
Fase

Características
 Iterativo. Refinamiento sucesivo
 Controlado. Gestión de requisitos y control de
cambios
 Construcción de modelos
 Centrado en la arquitectura.
 Desarrollo de software basado en componentes
 Conducido por los Casos de Uso
 Soporta técnicas OO. Uso del UML
 Configurable
 Fomento al control de calidad
 Soportado por herramientas

Modelo del Ciclo de Vida
Tiempo
Requisitos
Diseño
Implem.
Pruebas
Cascada
Iterativo
Análisis
R
A
I
P
D
R
A
I
P
D
R
A
I
P
D

Proceso unificado de desarrollo
Organización por Organización en el tiempo
COMPONENTES DE SOPORTE
COMPONENTES DEL PROCESO
Iteraciones
Inicial
Definición Elaborac. Construcción Transición
Elab.
#1
Elab.
#2
Const.
#1
Const.
#2
Const.
#N
Trans.
#1
Trans.
#2
FASESComponentes
Captura de Requisitos
Análisis
Diseño
Implementación
Pruebas
Puesta en Servicio
Modelado de la Organización
Gestión de Configuración y Cambios
Gestión del Proyecto
Entorno
Hitos

Organización por Componentes
 Agrupan las actividades de acuerdo a su
naturaleza
 Representan la estructura del Proceso.
 Expresados en términos de:
Flujos de trabajo y
actividades
ArtefactosTrabajadores

Énfasis en Ingeniería Telemática
COMPONENTES DEL PROCESO Definición Elaborac. Construcción Transición
FASES
Análisis
Diseño
Implementación
Pruebas
Puesta en Servicio
 Flujos de trabajo del proceso
 Modelado de la Organización: ¿Cuál es el problema?
 Captura de Requisitos: ¿Qué hace el sistema?
 Análisis: ¿Cómo funciona?
 Diseño: ¿Cómo se construye?
 Implementación: Archivos
 Pruebas
 Puesta en Servicio

Componentes de soporte
 Gestión de Configuración y Cambios
 Gestión del Proyecto
 Entorno (de desarrollo)
Entorno

Organización en el tiempo
 Describe los aspectos del ciclo de vida,
tal como se irán presentando.
 Representa la dinámica del Proceso.
 Expresada en términos de
 Ciclos, Fases, Iteraciones, Hitos.
 Ciclo: Desarrollo de una nueva versión
del producto

Fase
Iteración
Hito
Fases:
 Definición  Objetivos y plan
 Elaboración  Arquitectura
 Construcción  Producto
 Transición  Satisfacción del usuario
R
A&D
I
P
R
A&D
I
P
R
A&D
I
P

Cada Fase termina en un Hito y puede
estar dividida en Iteraciones.
Hito: Punto de control. Permiten a la
gestión evaluar el progreso.
Iteración: Unidad de desarrollo del
producto. Recorre los componentes de
manera total o parcial.
Las Fases/Iteraciones determinan el
énfasis de los Componentes

Componentes del Proceso y
Modelos
Captura de
Requisitos
Diseño
Implemen-
tación
Pruebas
Componentes del Proceso
Modelo de
Casos de Uso
Modelo de
Diseño
Modelo de
Implementac.
Modelo de
Pruebas
Código Objeto
OK
OK
Falla
Implementado
porRealizado por
Verificado por
Modelado
Organizac.
Modelo de la
Organización
Análisis
Modelo de
Análisis
Realizado por
Modelos

Modelo de la Organización
Lector Prestar Libro
Modelo de Casos
de Uso de la
Organización
:Catálogo:TarjetaLector :Libro
:Lector
:Director:Monitor
Modelo de
Objetos de la
Organización

Modelo de Casos de Uso
:Perfil :Cuenta :Crédito
:Cliente
:Analista:Asistente
Modelo de Objetos
de la Organización
Gestionar Préstamo
Más descripción
Cliente Solicitar Préstamo
AnalistaEstudiar Préstamo
Control Acceso

Modelo de Análisis
Usuarios
Analista
CtrlAccesoIU_Acceso
IU_Menu
Control Acceso
Analista
Vista de Casos de Uso
Diagrama de Clases de Análisis

Vista Lógica
EnProcesoconstructor()
Circulando
Prestado Reservado
Disponible
Prestado Reservado
prestar()
Disponible
retirar()
destructor()
exponer()
devolver()
borrarReserva()
reservar()prestar()
GestionEjempl
eliminarIEjempl()
crearEjempl()
ejemplAEstante()
ejemplATaller()
GestionReserva
consultarEjempl()
reservarEjempl()
borrarReserva()
GestionPréstamo
prestarEjempl()
devolverEjempl()
Ejemplar
codigo: Integer
cantidad: Integer
estado: Integer
exponer()
reservar()
borrarReserva()
prestar()
devolver()
retirar()
reponer()
: Monitor
: IU_Inicio : Gestión
Monitor
: Tarjeta
Monitor
: IU_MenuPpal
1: Activa
3: DiálogoID_Clave
Ingresa ID
y Clave
5: validarAcceso( ID, Clave)
6: buscarCódigo( ID)
7: leerContraseña( )
8: Activa
9: MenuMonitor
4: BotonAceptarClick( )
2: Activa
Interfaces
Gestión
Base de
Datos

Modelo de Diseño
Extensión para Aplicaciones Web
PC_Bienv
«links»
PC_Reg
Frm_Reg PS_PrReg
«submits»
PC_Conf
«builds»
«query»
AccBD

Seminario de Proceso Unificado
de Desarrollo - fase de Definición
(Gestación)
Presentación
Rodrigo Cerón
Popayán, agosto de 2020
Universidad del Cauca
Departamento de Telemática

Contenido
 Descripción general de la fase
 Preparación de la fase
 Un ejemplo de fase típica
 Ejecución de los componentes de
proceso
 Evaluación y plan para la fase de
elaboración
 Documentación de la fase

Ubicación de la fase
Énfasis en Ingeniería Telemática 23
Organización por Organización en el tiempo
COMPONENTES DEL PROCESO
Iteraciones
Inicial
Elab.
#1
Elab.
#2
Const.
#1
Const.
#2
Const.
#N
Trans.
#1
Trans.
#2
FASESComponentes
Análisis
Diseño
Implementación
Pruebas
Puesta en Servicio
Entorno
Hitos
31/08/2020

Descripción general de la fase
 Poner en marcha el proyecto
 Recopilación de objetivos, definir la
arquitectura del sistema, desarrollo del
modelo de negocio.
 Delimitación del problema a resolver,
estudio de riesgos y análisis de la
organización.
 Definición de “arquitectura candidata”

Contenido
proceso
elaboración

Preparación de la fase
 Conocer algo sobre la organización que
necesita el desarrollo
 Planificación de la fase de definición
(Recopilación de información,
organización, utilización y descubrir
carencias)
 Ampliación de la descripción del sistema
 Establecimiento de criterios de
evaluación

Criterios de evaluación
 Ámbito del sistema
 Ambigüedad en los requisitos de esta
fase
 Arquitectura candidata
 Riesgos críticos

Contenido
proceso
elaboración

Componentes de Proceso – Fase
de Definición
Requisitos Análisis Diseño Implementación Prueba
Recursos
Componentesde
proceso
Planificación de
la iteración
Evaluación de
la iteración

Fase de Definición en general
 Trabajo principal en requisitos
 Modelo de Análisis inicial
 Prototipo exploratorio cuando sea el
caso
 Descripción de la arquitectura candidata
 Ajuste del proyecto al entorno de
desarrollo
 Identificación de riesgos críticos

Contenido
proceso
elaboración

El proceso unificado de desarrollo
Diseñador
GUI
Arquitecto
Ingeniero
de caso de uso
Ingeniero
de componentes
Especificador
de caso de uso
Analista de
sistema
Ingeniero de
pruebas de
sistema
Ingeniero de
pruebas de
integración
Integrador
de sistemas
Ingeniero de
pruebas
Diseñar la
arquitectura
Diseñar
una clase
Diseñar un
caso de uso
Diseñar un
subsistema
Diseño
Encontrar actores
y casos de uso
Ordenar los
casos de uso
Detallar caso
de uso
Estructurar el
modelo de casos
de uso
Construir
prototipo de la
GUI
Requisitos
Análisis de la
arquitectura
Analizar un
caso de uso
Analizar
una clase
Analizar
un paquete
Análisis
Implementación
de la arquitectura
Implementar
un subsistema
Implementar una
clase
Prueba
unidad
Implementación
Integrar
sistema
Implementar
pruebas
Probar
sistema
Probar
integración
Planificar
pruebas
Diseñar
pruebas
Evaluar
pruebas
Pruebas

Actividades Fase de Definición
Diseñador
GUI
Arquitecto
Ingeniero
de caso de uso
Ingeniero
de componentes
Especificador
de caso de uso
Analista de
sistema
Ingeniero de
pruebas de
sistema
Ingeniero de
pruebas de
integración
Integrador
de sistemas
Ingeniero de
pruebas
Diseñar
una clase
Diseñar un
caso de uso
Diseñar un
subsistema
Diseño
Estructurar el
modelo de casos
de uso
Construir
prototipo de la
GUI
Requisitos
Analizar
una clase
Analizar
un paquete
Análisis
Implementación
de la arquitectura
Implementar
un subsistema
Implementar una
clase
Prueba
unidad
Implementación
Integrar
sistema
Implementar
pruebas
Probar
sistema
Probar
integración
Planificar
pruebas
Diseñar
pruebas
Evaluar
pruebas
Pruebas
Definir la arquitectura
candidata
Definir el ámbito
del sistemaEncontrar actores
y casos de uso
Ordenar los
casos de uso
Análisis de la
arquitectura
Diseñar la
arquitectura
Analizar un
caso de uso
Detallar caso
de uso

Recopilación de Requisitos
Identificar y detallar los casos de uso
pertinentes
 Enumerar los requisitos a figurar
 Comprender el contexto del sistema
 Representar los requisitos funcionales
como casos de uso
 Recoger los requisitos no funcionales

Representación de requisitos como
casos de uso
Trabajo principal en:
 Encontrar actores y casos de uso
 Ordenar los casos de uso (dar prioridad)
 Detallar casos de uso
Poco trabajo en:
 Construir prototipo de GUI
 Estructurar el modelo de casos de uso

Captura de requisitos como casos
de uso
Analista de
sistemas
Actor
GlosarioModelo de
Casos de uso
Especificador
de casos de uso
Casos de uso
Diseñador
de interfaz de usuario
Prototipo de interfaz
de usuario
Arquitecto
Descripción de
la arquitectura

Análisis
 Análisis de la arquitectura
 Analizar un caso de uso
Poco trabajo en:
 Analizar una clase
 Analizar un paquete

Análisis
Arquitecto
Modelo de
análisis
Glosario
Especificador
de casos de uso
Realización de
caso de uso - Análisis
Ingeniero de
componentes
Clase de Análisis
Paquete del
análisis

Diseño
 Diseño de la arquitectura
Poco trabajo en:
 Diseñar un caso de uso
Trabajo mínimo en:
 Diseñar una clase
 Diseñar un subsistema

Diseño
Arquitecto
Modelo
de diseño
Modelo
de despliegue
Descripción de
la arquitectura
Ingeniero de
casos de uso
Realización de
caso de uso – diseño
Ingeniero de
componentes
Clases
del Diseño
Subsistema
de diseño
Interfaz

Implementación
Poco trabajo en:
 Implementación de la arquitectura
Trabajo mínimo en:
 Integrar sistema
 Implementar un subsistema
 Implementar una clase
 Realizar pruebas de unidad

Implementación
Arquitecto
Modelo de
implementación
Descripción de
la arquitectura
Modelo de
despliegue
Integrador
de sistema
Integración del
sistema
Ingeniero de
componentes
Componente
Implementación de
subsistema
Interfaz

Contenido
proceso
elaboración

Evaluación de la fase de definición
 Criterios establecidos al inicio de la fase
 Criterios no alcanzables:
 Ampliación de los casos de uso
 Desarrollo de prototipo de demostración
 No encontrar los riesgos críticos
 Plan de emergencia de los riesgos críticos

Planificación de la fase de
elaboración
Modelo de
organización
Casos de uso
identificados
Casos de uso
descritos
Casos de uso
analizados
Casos de uso
diseñados,
implementados y
probados
Fase de
Definición
50-70% 50% 10% 5%
Un pequeño
porcentaje para
el prototipo
Fase de
Elaboración
Casi el 100% 80% o más 40-80% 20%-40% Menos del 10%
Fase de
Construcción
100% 100% 100%
100% si se
mantienen
100%

Contenido
proceso
elaboración

Documentación de la fase
 Lista de características
 Modelo de negocio u organización
(primera versión)
 Modelos de casos de uso, modelo de
análisis y modelo de diseño (primera
versión)
 Descripción de la arquitectura candidata,
vistas de casos de uso, análisis, diseño
e implementación

Documentación de la fase
 Prototipo exploratorio (opcional)
 Lista de riesgos, clasificación de los
casos de uso (inicial)
 Plan de proyecto (inicial), plan general
de las fases (inicial)
 Características económicas relacionadas
con el proyecto.

Apuntes sobre el modelo de
análisis

Vista de
Componentes
(Implementación)
Vista Lógica
Vista de Procesos
(Concurrencia)
Vista de Implantación
(Despliegue)
Vista de
Casos de Uso
Vocabulario
Funcionalidad
Ensamblado del sistema
Gestión de la configuración
Funcionamiento
Crecimiento
Rendimiento
Topología
Distribución
Entrega
Instalación

Vista Lógica
 Muestra el diseño de la funcionalidad del
sistema: Estructura y Comportamiento
 Para equipos de diseño y desarrollo
 Descripción de estructura:
 Diagramas de clases y de objetos
 Descripción de comportamiento:
 Diagramas de secuencia, colaboración,
estado y actividades

Vista Lógica
: Monitor
Monitor
: Tarjeta
Monitor
: IU_MenuPpal
1: Activa
3: DiálogoID_Clave
Ingresa ID
y Clave
5: validarAcceso( ID, Clave)
6: buscarCódigo( ID)
8: Activa
9: MenuMonitor
2: Activa
GestionEjempl
eliminarIEjempl()
crearEjempl()
ejemplAEstante()
ejemplATaller()
GestionReserva
consultarEjempl()
reservarEjempl()
borrarReserva()
GestionPréstamo
prestarEjempl()
devolverEjempl()
Ejemplar
codigo: Integer
cantidad: Integer
estado: Integer
exponer()
reservar()
borrarReserva()
prestar()
devolver()
retirar()
reponer()
Interfaces
Gestión
Base de
Datos
Circulando
Prestado Reservado
Disponible
Prestado Reservado
prestar()
Disponible
retirar()
destructor()
exponer()
devolver()
borrarReserva()
reservar()prestar()

Fase de Definición
Modelo de Casos
de Uso
Para qué (y a quién)
sirve el sistema?
Modelo de la
Organización
Cuál es el problema?

Modelo de
Análisis
Cómo funciona el
sistema?
Modelo de Casos
de Uso
Para qué (y a quién)
sirve el sistema?
Análisis del Software

Modelo de casos de uso
Lector
SI_Admnistrativo Consultar
Multas
Control Acceso
Hacer Consulta
Director
Hacer Reserva
<<extend>>
Borrar Reserva
Prestar Item
<<include>>
Registrar Nuevo
Lector
Monitor
Lector hace reserva
Gestionar Monitores
Usuario
LectorLector
Multas
Multas
Control Acceso
Hacer Consulta
Director
Hacer Reserva
<<extend>>
Borrar Reserva
Prestar Item
<<include>>
Registrar Nuevo
Lector
Monitor
Lector hace reserva
Gestionar Monitores
UsuarioControl AccesoControl Acceso
Hacer Consulta
DirectorDirector
Hacer Reserva
<<extend>>
Borrar Reserva
Prestar ItemPrestar Item
<<include>>
Registrar Nuevo
Lector
Monitor
Lector hace reserva
Gestionar Monitores
UsuarioUsuario
Más descripción

Caso de uso de alto nivel
 Caso de uso: Hacer Reserva
 Actores: Monitor (iniciador)
 Tipo: Primario
 Descripción:
 El Monitor solicita al sistema reservar un ítem
solicitado por un Lector.
 El sistema verifica la información del ítem y del
Lector.
 El sistema verifica e informa la disponibilidad del
ítem solicitado.
 El sistema modifica el estado del ítem,
asignándolo al Lector.

Caso de Uso Extendido
S-nS-1
Flujo
Principal
[Precondición]
…
Subflujos
E-m
E-1
Flujos de
Excepción
Info.
General

Caso de Uso Extendido (1)
 Caso de uso: Hacer Reserva
 Actores: Monitor (iniciador)
 Propósito: Asignar a un Lector un libro para que
pueda retirarlo más tarde.
 Resumen: El Monitor ingresa la información del
Lector y del libro solicitado. El sistema verifica e
informa la disponibilidad del libro solicitado, y
modifica el estado del ítem, asignándolo al Lector.
 Tipo: Primario y abstracto
 Referencias cruzadas: Funciones: R1.1, R1.6.
Casos de Uso: Control de Acceso, Hacer
Consulta.

Precondición
 El sistema debe contar con la siguiente
información:
- Información del Lector: Código, nombre, estado
(Activo, Suspendido, etc.).
- Información de los libros: Código, título, estado
(Disponible, Reservado, Prestado, etc.).
 El Monitor debe ejecutar el caso de uso
Control de Acceso.
 Puede iniciarse con el caso de uso Hacer
Consulta

Flujo Principal
- Este caso de uso empieza cuando el Monitor elige en
el menú principal del sistema la opción Reserva.
- El sistema presenta al Monitor
el Formulario de Reserva de la
Figura 1, que solicita el código
del Lector y el código del libro
a reservar.
Figura 1. Formulario de reserva

Flujo Principal (cont.)
- El Monitor captura total o parcialmente la información
de reserva, y selecciona una de las opciones del final
del formulario: Aceptar y Cancelar.
- Si elige la opción Aceptar, Subflujo S1: Verificar
Lector y Estado de un Libro.
- Si elige la opción Cancelar, Subflujo S2: Cancelar la
Reserva de un Libro.

Subflujos
 S1: Verificar Lector y Estado de un Libro.
- El sistema verifica el código del Lector (E1, E2).
- El sistema verifica el código del libro solicitado (E3)
- El sistema consulta el estado del libro solicitado.
- Si el libro solicitado está disponible, el sistema modifica su
estado a Reservado, lo asigna al Lector indicado al comienzo, y
presenta al Monitor el cuadro de diálogo de la Figura X para
informarle del éxito de la operación. Cuando el Monitor pincha
Aceptar el sistema regresa al Menú Principal.
- Si el libro solicitado está reservado o prestado, el sistema
presenta al Monitor el cuadro de diálogo de la Figura Y (...)

Subflujos (cont.)
 S2: Cancelar la Reserva de un Libro.
- El sistema despliega el mensaje de la Figura S
solicitando confirmar la cancelación.
- El Monitor presiona el botón Aceptar.
- El sistema regresa al Menú Principal.

Flujos de excepción
 E1: Lector suspendido.
- El sistema despliega el mensaje de la Figura W
informando que el Lector está suspendido
- El Monitor presiona el botón Aceptar.
- El sistema regresa al Menú Principal.
 E2: Código del Lector no válido.
- El sistema despliega un mensaje de error de la
Figura Z informando que el código del Lector no
es válido
- ...

Construcción de la Vista Lógica
Vista de Casos de Uso
Control Acceso
Usuario
Vista Lógica
: Usuario
Monitor
: Tarjeta
Monitor
: IU_MenuPpal
1: Activa
3: DiálogoID_Clave
Ingresa ID
y Clave
5: validarAcceso(ID, Clave)
6: buscarCódigo(ID)
8: Activa
9: MenuMonitor
2: Activa
TarjetaMonitor
Usuario
GestiónMonitorIU_Inicio
IU_MenuPpal

Proceso iterativo
 Identificar clases
 Identificar interacciones entre objetos
 Especificar relaciones entre clases
 Incorporar comportamiento y estructura
 Analizar comportamiento de objetos
 Verificar el modelo
Guiado por escenarios  Casos de Uso

Identificar clases
 Identificar interacciones entre objetos
 Especificar relaciones entre clases
 Incorporar comportamiento y estructura
 Analizar comportamiento de objetos
 Verificar el modelo

Identificación de clases
 Categorías de clases:
 Entidad (Entity): Modelado de información
 Frontera (Boundary): Modela las
comunicaciones con el exterior
 Control (Control): Modela el comportamiento
 Excepción (Exception): Gestiona
excepciones

Ejemplo
Caso de uso: Control de Acceso
Actores: Usuario (iniciador)
Tipo: Primario
Descripción:
– El Usuario activa al sistema.
– El sistema solicita al Usuario su Identificación y Clave.
– El sistema verifica Identificación y Clave del Usuario.
– El sistema presenta al Usuario el menú principal.

Ejemplo: Control de acceso
Usuario
«Entity»
TarjetaMonitor
«Entity»
TarjetaMonitor
leerId()
leerContraseña()
actContraseña()
id : String
contraseña : String
 El sistema verifica Identificación y Clave del Usuario

Clases de Entidad
 Reflejan el mundo real o se crean para
tareas internas
 No dependen del entorno del sistema
 Pueden ser independientes de la
aplicación
 Se obtienen examinando la
responsabilidades del sistema en los
casos de uso

Usuario
«Entity»
TarjetaMonitor
«Boundary»
IU_Acceso
 El sistema solicita al Usuario su Identificación y Clave

Usuario
«Boundary»
IU_Acceso
«Boundary»
IU_Acceso
botAceptarClick()
activar()
botCancelarClick()
ocultar()
color : Color
posicion : XYCoord
TLabel TLabel
TEdit
TLabel
TEditTImage
TBitButton
TBitButton
+Mensaje +EtiqNombreUsr
+NombreUsr
+EtiqClave
+Llave
+BotonAceptar
+BotonCancelar+Clave

Clases de Frontera
 Proveen la interfaz con el usuario o con
otros sistemas
 Dependen del entorno del sistema
 Se obtienen examinando las relaciones
actor-escenario en los casos de uso
 Se refinan durante el diseño para
considerar los protocolos de
comunicación

Usuario
«Control»
GestionMonitor
«Boundary»
IU_Acceso
«Entity»
TarjetaMonitor
 El sistema solicita al Usuario su Identificación y Clave.
 El sistema verifica Identificación y Clave del Usuario.
 El sistema presenta al Usuario el menú principal.

Monitor
«Boundary»
IU_MenuPpal
«Boundary»
IU_Acceso
«Entity»
TarjetaMonitor
«Control»
GestionMonitor
crearMonitor()
validarAcceso()
actualizarMonitor()
borrarMonitor()
«Control»
GestionMonitor

Clases de Control
 Coordinan los eventos necesarios para
implementar el comportamiento
especificado en el caso de uso
 Son dependientes de la aplicación
 Al comienzo, existe una clase de control
para cada par actor-caso de uso

Diagrama de Clases de Análisis
Usuario
TarjetaMonitorGestionMonitor
IU_Acceso
IU_MenuPpal

Diagrama de Paquetes
Gestión
GestionMonitor
crearMonitor()
validarAcceso()
actualizarMonitor()
borrarMonitor()
GestionLector
crearLector()
actualizarLector()
borrarLector()
GestionEjempl
consultarEjempl()
reservarEjempl()
borrarReserva()
prestarEjempl()
devolverEjempl()
Interfaces Base de
Datos
Gestión

Construcción de la Vista
Lógica
Identificar interacciones entre objetos
 Especificar relaciones entre clases

Diagrama de Clases Inicial
Interacciones entre objetos:
Se identifican en el flujo de eventos descrito
en el Caso de Uso
«Boundary»
IU_MenuPpal
«Control»
GestionMonitor
«Boundary»
IU_Inicio
«Entity»
TarjetaMonitor

Caso de Uso Control de Acceso
Caso de uso: Control de Acceso
Actores: Usuario (iniciador)
Tipo: Primario
Flujo Principal:
 El Usuario activa al sistema.
 El sistema presenta al Usuario la ventana de diálogo de
la Figura 1 para solicitarle su Identificación y Clave.
 El Usuario ingresa su Identificación y Clave y
selecciona una de las opciones : Aceptar y Cancelar.
 Si elige la opción Aceptar, Subflujo S1: Verificar
Identificación y Clave del Usuario
 Si elige la opción Cancelar, Subflujo S2: ...

Diagrama de Secuencias Inicial
: Usuario
: IU_Acceso : Gestión
Monitor
: Tarjeta
Monitor
: IU_MenuPpal
Activa
Solicita ID+Clave
ID+Clave
Consulta ID+Clave
Activa
Muestra Menu Monitor
Activa
ID+Clave

Especificar relaciones entre clases

Relaciones entre clases
 Resultan de examinar los escenarios
(Diagrama de Secuencia).
 Los mensajes entre objetos indican
relaciones entre éstos.
«Control»
GestionMonitor
«Entity»
TarjetaMonitor
: Gestión
Monitor
: Tarjeta
Monitor
Consulta ID+Clave

Diagrama de Clases con
Relaciones
«Boundary»
IU_MenuPpal
«Control»
GestionMonitor
«Entity»
TarjetaMonitor
«Boundary»
IU_Acceso
TLabel
TImage
TBitButton
TEdit
1 1..*
Consulta ID_Clave
Activa
Obtiene ID_Clave

Incorporar comportamiento y estructura

Comportamiento y Estructura
 Comportamiento: Operaciones
 Los mensajes en el Diagrama de
Secuencias  operación en clase receptora
 Casos especiales: actores y clases de
frontera
 Estructura: Atributos
 Se encuentran en el planteamiento del
problema, los requerimientos y los casos de
uso

Diagrama de Secuencias con
Operaciones
: Usuario
: IU_Acceso : Gestión
Monitor
: Tarjeta
Monitor
: IU_MenuPpal
1: Activa
3: DiálogoID_Clave
Ingresa ID
y Clave
8: Activa
9: MenuMonitor
4: botonAceptarClick( )
2: Activa

Diagrama de Colaboración
: Usuario
: IU_
Acceso
: Gestión
Monitor
: Tarjeta
Monitor
: IU_Menu
Ppal
1: Activa
3: DiálogoID_Clave
4: botonAceptarClick( )
8: Activa9: MenuMonitor
2: Activa

Diagrama de Clases con Atributos y
Operaciones
«Boundary»
IU_MenuPpal
TLabel
TImage
TBitButton
TEdit
1 1..*
«Boundary»
IU_Acceso
botAceptarClick()
activar()
botCancelarClick()
ocultar()
color : Color
posicion : XYCoord
«Entity»
TarjetaMonitor
leerId()
leerContraseña()
actContraseña()
id : String
contraseña : String
«Control»
GestionMonitor
crearMonitor()
validarAcceso()
actualizarMonitor()
borrarMonitor()
Consulta ID_Clave
Activa
Obtiene ID_Clave
Operaciones  Mensajes
Atributos  Requisitos

Analizar comportamiento de objetos

Diagrama de Estados
Circulando
Prestado Reservado
Disponible
Prestado Reservado
prestar()
Disponible
retirar()
destructor()
exponer()
devolver()
borrarReserva()
reservar()prestar()
GestionEjempl
eliminarIEjempl()
crearEjempl()
ejemplAEstante()
ejemplATaller()
GestionReserva
consultarEjempl()
reservarEjempl()
borrarReserva()
GestionPréstamo
prestarEjempl()
devolverEjempl()
Ejemplar
codigo: Integer
cantidad: Integer
estado: Integer
exponer()
reservar()
borrarReserva()
prestar()
devolver()
retirar()
reponer()
31/08/2020 Énfasis en Ingeniería Telemática 93

Analizar comportamiento de objetos
Verificar el modelo

Verificación del Modelo
 Combinar clases
 Duplicadas o similares
 Dividir clases
 “Una clase debe hacer una sola cosa y hacerlo bien!”
 Eliminar clases
 Sin operaciones o atributos. No participa en Casos
de Uso
 Verificación de consistencia
 Estructura (estática) vs comportamiento (dinámica)
 Recorrido (walk-through) de escenarios
 Revisión de la documentación

Referencias
 Ivar Jacobson, Grady Booch and James Rumbaugh. “The Unified
Software Development Process”. Addison-Wesley. 1998.
 Philippe Kruchten. “The Rational Unified Process, An
Introduction”. Addison-Wesley. March 2000
 C. Larman. "Applying UML and Patterns. An Introduction to
Object-Oriented Analysis and Design". Prentice-Hall. 1998
 Rational. "Rational Unified Process: Best Practices for Software
Development Teams".
http://www.ibm.com/developerworks/rational/library/253.html.
 Rational Unified Process Home Page.
http://www.ibm.com/software/awdtools/rup/

Preguntas

s02E42020-1

Más contenido relacionado

La actualidad más candente (14)

Similar a s02E42020-1 (20)

Más de Mario Solarte (20)

Último (20)

s02E42020-1