Semana 4 El Modelo de Diseño 2019.1 PDF

EL MODELO DEL DISEÑO
Semana 4
Universidad Nacional Mayor de San Marcos © NMC

E.A.P. de Ingeniería de Sistemas
El Proceso Unificado de Desarrollo
Es un proceso de ingeniería del software que agrupa las 6 mejores prácticas

de desarrollo software que existen en el mercado.
Tiempo
Caracterisiticas
• Está basado en
Contenido
componentes e
interfaces bien definidas
• Utiliza el Lenguaje
Unificado de Modelado
(UML)
• Aspectos característicos:
• Dirigido por casos de uso
• Centrado en la arquitectura
• Iterativo e incremental
Universidad Nacional Mayor de San Marcos

Fase Requisitos: Artefacto
Pieza de información utilizada o producida por un proceso de

desarrollo de software
Artefactos implicados durante la captura de requisitos
• Modelo de Casos de Uso
• Actor
n
• Glosario
• Caso de Uso
• Prototipo de Interfaz de Usuario
• Descripción de la Arquitectura

Work Flow

Flujo de Trabajo de Requisitos
Encontrar Actores Estructurar el Modelo

y Casos de Uso de Casos de Uso
Analista de Sistemas
Arquitecto Priorizar
los Casos de Uso
Detallar
Especificador CU los Casos de Uso
Diseñador de Interfaz
de usuario Prototipar
la Interfaz de Usuario

Work Flow de Análisis
Ofrecer una especificación más precisa de los requisitos que la

que tenemos como resultado de los requisitos.
Análisis
de la
Arquitectura
Arquitecto
Analizar un
Caso de Uso
Ingeniero de
casos de uso
Ingeniero de
Analizar Analizar
Componentes una clase un
paquete

Work Flow de Diseño
Diseño
de la
Arquitectura
Arquitecto
Diseñar un
Caso de
Uso
Ingeniero de
casos de uso
Ingeniero de
Diseñar Diseñar un
Componentes una subsistema
clase

Work Flow de Implementación
Implementació
n de la
Arquitectura
Arquitecto
Integrar
sistemas
Integrador
de sistemas
Ingeniero de Implementar
Componentes un subsistema
Implementar
una clase Realizar prueba
de unidad

Work Flow de Pruebas
Planificar Diseñar prueba Evaluar prueba

Ingeniero de pruebas Pruebas
Ingeniero de pruebas Realizar Prueba

de integración de integración
Ingeniero de pruebas Realizar prueba

de sistema de sistema
Ingeniero de
componentes Implementar
Prueba

Fases del proceso

Fase de inicio
Objetivo: Establece la viabilidad del proyecto
Se fundamenta el
análisis de negocio
inicial: Productos de la fase:
• Se delimita el • Lista de características
ámbito del sistema • Primera versión del modelo del negocio
• Se propone o • Primera versión del modelo de casos de uso, de
esboza una
análisis y de diseño
arquitectura del
sistema • Descripción de la arquitectura candidata
• Se identifican • Prototipo exploratorio
riesgos críticos • Lista inicial de riesgos y clasificación de casos de uso
• Se demuestra a los • Plan para el proyecto
usuarios la utilidad • Primer borrador del análisis del negocio
del sistema
propuesto
Modelo Casos de uso Casos de uso Casos de uso Casos de uso

negocio identificados descritos analizados diseñados, Hito : Objetivos
implementados
y probados (visión)
Fase inicio 50% -70% 50% 10% 5% Lo suficiente
para el prototipo
Fase Cerca del >80% 40% - 80% 20% - 40% <10%

elaboración 100%
Fase 100% 100% 100% 100% si se 100%

construcción mantiene

Fase de elaboración
Objetivos: Elaborar una arquitectura estable, Conocer

suficientemente el sistema como para planificar en detalle
la fase de construcción
Productos
Tareas básicas:
• Modelo del negocio completo
• Crear una línea base para la
arquitectura • Versión de los modelos
• Identificar riesgos significativos • Línea base de la arquitectura
• Especificar atributos de calidad • Lista de riesgos actualizada
• Estudiar 80% de los requisitos
• Plan de proyecto para construcción y
funcionales
transición
• Manual de usuario (opcional)
• Análisis del negocio completo
Hito : Arquitectura

Fase de construcción
Objetivo: La capacidad de operación inicial.

Versión beta, requiere mayor número de
iteraciones
Tareas básicas: Productos
• Extensión a todos los casos • El plan de proyecto para la fase
de uso de transición
• Finalización del análisis, • El sistema software ejecutable
diseño, implementación y • Todos los artefactos
prueba • La descripción de la arquitectura
• Mantenimiento de la actualizada
integridad de la • Versión preliminar del manual de
arquitectura usuario
• Monitorización de los • Análisis del negocio actualizado
riesgos críticos y
significativos.
Hito : Funcionalidad operativa

Fase de transición
• Objetivos: Despliegue del producto en el cliente
Tareas: Productos:
• El sistema software ejecutable + software
• Completa la versión del producto
instalación
• Se gestionan los aspectos relativos al
• Documentos legales, contratos, licencias,
entorno del cliente garantías
• Se corrigen los defectos de la versión • Versión completa y corregida del producto,
beta incluyendo los modelos del sistema
• Se terminan los manuales de usuario • La descripción de la arquitectura completa
y cursos de formación y actualizada
• La atención se desplaza a la • Manuales y material de formación del
corrección de defectos usuario, del operador y del administrador
• Referencias para la ayuda del cliente, cómo
informar de defectos
Hito : Release del producto

El Proceso Unificado de Rational - RUP
El Rational Unified Process fue el resultado de una convergencia de

Rational Approach y Objectory (el proceso de la empresa Objectory
AB). El primer resultado de esta fusión fue el Rational Objectory
Process, la primera versión de RUP, fue puesta en el mercado en 1998,
siendo el arquitecto en jefe Philippe Kruchten.

Elementos de RUP
Con RUP, un proceso de desarrollo es representado usando un conjunto de

elementos de modelado. En RUP se encuentran 4 elementos básicos, los roles el
quién, las actividades el cómo, los artefactos el qué y los flujos de trabajo el
cuándo.
Elementos Básicos De RUP

Elementos de RUP

Vistas de la arquitectura de RUP
vocabulario, ensamblado del

funcionalidad sistema,
Vista de gestión de
Vista de diseño configuraciones
implementación
comportamiento Vista de
casos de uso
Vista de Vista de
procesos despliegue
Funcionamiento, topología del

capacidad de sistema,
crecimiento, distribución,
rendimiento entrega,
instalación

EL MODELO DE DISEÑO

El modelo de diseño
• El modelo de diseño puede verse en dos dimensiones

diferentes
• La dimensión del proceso: la cual indica la evolución del diseño

conforme se ejecutan las tareas de diseño como una parte del
proceso de SW.
• La dimensión de Abstracción: la cual representa el grado de
detalle a medida que cada elemento del modelo de análisis se
transforma en un equivalente del diseño y después se refina de
manera iterativa.

El modelo de diseño
• Los elementos del modelo del diseño utilizan muchos de los diagramas
en UML aplicados en el modelo de análisis.
• La diferencia es el nivel de refinamiento y elaboración existente en
estos últimos
• Proporcionan un mayor detalle para la implementación específica
• Se resalta la estructura y el estilo arquitectónico, los componentes
que residen dentro de la arquitectura y las interfaces entre los
componentes y con el mundo exterior.
• En la mayoría de los casos,
• el diseño arquitectónico preliminar establece la plataforma y lo siguen el diseño de
interfaz y el diseño a nivel de componentes, los cuales a menudo se realizan en
paralelo.
• El modelo de despliegue con frecuencia se retrasa hasta que el diseño
ha sido desarrollado por completo

1. Elementos del diseño de datos
• El diseño de datos (algunas veces llamado arquitectura de

datos), crea un modelo de datos o información que se
representa con un alto grado de abstracción (la visión de
los datos del cliente/usuario).
• Después este modelo se refina en representaciones que de
manera progresiva tienen una implementación específica y
que pueden procesarse mediante el sistema basado en
computador.
• En muchas aplicaciones de SW, la arquitectura de los
datos tendrá una profunda influencia sobre la arquitectura
del SW que los debe de procesar.

Ejemplo

Ejemplo

1. Elementos del diseño de datos
• Importancia de la estructura de datos

• A nivel de los componentes del sistema: las estructuras del
diseño de datos y de algoritmos con que se manipulan son
esenciales para la creación de aplicaciones de alta calidad.
• A nivel de aplicación: La traducción de un modelo de datos
(obtenidos de la Ing. de requisitos) a una BD es esencial para
alcanzar los objetivos de negocio de un sistema.
• A nivel de negocios: La colección de información
almacenada en BD dispersas y reorganizadas en una
“colección de datos” permite la explotación de datos o el
descubrimiento de un conocimiento que puede tener un
impacto sobre el éxito del mismo negocio.

2.Elementos del diseño arquitectónico
• El diseño arquitectónico para el SW es como el plano de

planta de una casa.
• Los elementos del diseño arquitectónico dan una visión
general de SW.
• El modelo arquitectónico se obtiene de 3 fuentes:
• La información acerca del dominio de aplicación para el SW
que se va a construir.
• Los elementos del modelo de análisis en específico, tales
como diagramas de flujo de datos o clases de análisis, sus
relaciones y colaboraciones para el problema que se tiene a la
mano.
• La posibilidad de patrones y estilos arquitectónicos

3. Elementos del diseño de interfaces
• El diseño de interfaz parar SW es el equivalente a un

conjunto de dibujos detallados (y especificaciones) para
puertas, ventanas y utilidades externas de una casa.
• En esencia, los dibujos (y especificaciones) detallados para
las puertas, ventanas y utilidades externas indican cómo
fluyen las cosas y la información desde y hacia la casa y
dentro de las habitaciones que son parte del plano de la
planta.
• Los elementos del diseño de interfaz para SW muestran
como fluyen la información hacia o fuera del sistema y
cómo éste está comunicado entre los componentes
definidos como parte de la arquitectura.

• Elementos importantes del diseño:

• La interfaz con el usuario.
• Las interfaces externas a otros sistemas, artefactos, redes u
otros productores o consumidores de información.
• Interfaces internas entre varias componentes de diseño.
• Estos elementos permiten al SW la comunicación de
manera externa y la comunicación y colaboración interna
entre los componentes que pueblan la arquitectura del
SW.
• El diseño de interfaces incorpora elementos estéticos ,
ergonómicos y elementos técnicos.

Ejemplo

• El diseño de las interfaces externas requiere información

definitiva acerca de la entidad hacia donde se manda o
recibe información.
• En todos los casos, esta información debe recopilarse en la
ingeniería de requisitos y verificarse al inicio del diseño de la interfaz
• El diseño de interfaces externas debe incorporar revisión de errores
y apropiadas de seguridad, cuando estás sean necesarias.
• El diseño de interfaces internas está cercanamente
alineado con el diseño al nivel de los componentes.
Las realizaciones del diseño de clases de análisis representan todas las

operaciones y esquemas de mensajes requeridos para permitir la
comunicación y colaboración entre las operaciones de varias clases.

3.Elementos del diseño de interfaces
• Cada mensaje debe ser diseñado para ajustarse a la

transferencia de información de requisitos y los
requerimientos funcionales específicos de la operación que
ha sido solicitada.
• En algunos casos la interfaz se modela de forma muy
parecida a una clase.
• UML--> Interfaz es un determinante de las operaciones
[públicas] visibles de manera externa de una clase,
componente u otro clasificador (incluidos subsistemas) sin
especificación de estructura externa.
Una interfaz es un conjunto de operaciones que describe
parte del comportamiento de una clase y proporciona
acceso a esas operaciones.

4. Elementos del diseño a nivel de componentes
El diseño a nivel de componentes de SW equivale a un

conjunto de dibujos detallados para cada cuarto de la
casa.
• Para el SW: Describe por completo el detalle interno de
cada componente del SW.
• Para lograrlo se definen unas estructuras de datos para
todos los objetos locales, así como detalle algorítmico
para todo el procesamiento que ocurre dentro de un
componente y una interfaz que permite el acceso a todas
las operaciones de los componentes (comportamientos).

4. Elementos del diseño a nivel de componente
Los detalles de diseño a nivel de componentes se pueden

modelar a muchos grados distintos de abstracción.
• En la representación del procesamiento lógico se puede utilizar un
diagrama de actividad.
• El flujo detallado del procedimiento para un componente puede
representarse, ya sea mediante un Pseudocódigo o algún formato
diagramático (por ej.- Diagrama de actividad o un diagrama de flujo)

Ejemplo

5. Elementos de diseño a nivel del despliegue
• Los elementos de diseño a nivel de despliegue indican

como se ubicarán la funcionalidad y los subsistemas
dentro del entorno computacional físico que soportará
al SW.
• Durante el diseño se desarrolla un diagrama de despliegue
en UML y después se refina

Ejemplo

Diseño del SW basado en Patrones
• Los mejores diseñadores en cualquier campo tienen la

misteriosa habilidad de vislumbrar patrones que
caracterizan un problema y los patrones correspondientes
que pueden combinarse para crear una solución.
• A través del proceso de diseño un Ingeniero de SW debe
buscar toda oportunidad para reutilizar patrones de
diseños existentes (cuando cumplen la necesidad de un
diseño) en vez de crear nuevos.

Utilización de patrones en el diseño
• Los patrones de diseño pueden usarse en el desarrollo del

SW una vez que se ha desarrollado el modelo de análisis.,
ante lo cual el diseñador puede examinar una
representación detallada del problema que se debe
resolver y las restricciones que impone el problema.
• La descripción del problema se examina en varios grados
de abstracción para determinar si es flexible para uno o
más de los siguientes tipos de patrones de diseño.
• Patrones arquitectónicos: Definen la estructura general del
SW, indican relaciones entre los subsistemas y los
componentes del SW, y definen las reglas para especificar las
relaciones entre los elementos (Clases, paquetes,
componentes, subsistemas) de la arquitectura.

Ejemplo: Patrones de Arquitectura

Utilización de patrones de diseño
• Patrones de Diseño: Estos patrones se aplican a un

elemento específico del diseño como un agregado de
componentes para resolver algún problema de diseño,
relaciones entre los componentes o los mecanismos para
efectuar la comunicación de componente a componente.
• Patrones de Idiomas: También llamados patrones de
código, estos patrones específicos de lenguaje por lo
general implementan un elemento algorítmico o un
componente, un protocolo de interfaz específico o un
mecanismo de comunicación entre los componentes.
• Cada uno de los patrones difiere en el grado de
abstracción con el que está representado y con el grado
en el que proporciona una guía directa para la actividad
de codificación del proceso de SW.
Ejemplo : Patrón de Diseño

Ejemplo : Patrón de código

MODELADO DE CASOS
DE USO

Modelado de Casos de Uso
• Un caso de uso especifica un comportamiento

deseado del sistema.
• Representan los requisitos funcionales del
sistema.
“Un caso de uso especifica un conjunto de
secuencias de acciones, incluyendo variantes,
que el sistema puede ejecutar y que produce un
resultado observable de valor para un particular
actor.” Definición en UML)
• Describen qué hace el sistema, no cómo lo hace.
46
Que es un Caso de Uso
• Un caso de uso es un conjunto de escenarios

que tienen una meta de usuario en común
• Es una descripción de un proceso inicio-a-fin,
que incluye varias etapas o transacciones
• Es una manera específica de utilizar el sistema,
es una historia que describe un uso particular del
sistema
• Es la imagen de una funcionalidad del sistema,
desencadenada en respuesta al estímulo de un
actor o rol externo

Actor de Sistema
Un actor representa el rol jugado por una persona o

cosa que actúa con el sistema.
“Cliente, Administrador, Usuario no Registrado (Autenticado),

Usuario Registrado (Autenticado), Jefe de Compras, Jefe de
Personal, Moderador, Jefe de Departamento, Obrero de
Planta, Supervisor...”

Actor de Sistema
NO TODOS los stakeholders en el

sistema, sólo son actores aquellos que
utilizarán el sistema

Casos de Uso -Observaciones
• los casos de uso son de vital importancia en los

proyectos de software (Procesos Guiados por Casos de
Uso)
• Describen bajo la forma de acciones y reacciones el

comportamiento de un sistema desde el punto de
vista de un usuario
• Se puede considerar que hasta cierto nivel, cada

caso de uso es independiente de los demás
• Permiten definir los límites del sistema y las
relaciones entre el sistema y su entorno

Casos de Uso - Algunas Características
Un caso de uso NO es un diagrama, NO es un

símbolo dentro de un diagrama...
...es una forma de describir un escenario de

interacción usuario sistema...
...los diagramas vienen después (o antes) y

son una forma de tener una visión general de
los casos de uso, sus relaciones con los
actores y con otros casos de uso
Modelado de Casos de Uso
• Partes de un caso de uso (cdu)

• Conjunto de secuencias de acciones; cada
secuencia representa un posible comportamiento del
sistema
• Actores, roles que pueden jugar los usuarios
• Variantes: versiones especializadas, un cdu que
extiende a otro o un cdu que incluye a otro
• Un caso de uso realiza un trabajo tangible.
52
Modelo de Casos de Uso

¿Qué es un Escenario?

¿Qué es un Escenario?
Es una secuencia de acciones e interacciones

(pasos) entre los usuarios (actores) y el sistema

Escenario
Emisor Centralita Receptor
listo( )
tono
marcar_numero
tono_sonando
timbre_sonando
telefono_cogido
para_tono
para_timbre
Los Casos de uso son ideados por Jacobson a principios de los noventa y
están inspirados en los Escenarios utilizados para describir procesos.
Diagrama de Casos de Usos
Antes de hacer un caso de uso es necesario tratar de

entender los requerimientos del sistema. expresar lo que el
sistema debe hacer:
...el sistema debe permitir a los usuarios registrarse. El
administrador debe poder validar las peticiones de registro antes de
que los usuarios puedan publicar nuevos mensajes...
trate de responder las preguntas:
¿Que datos debe el actor

¿Cuales son las tareas de los
crear, guardar, modificar,
actores involucrados?
destruir, leer?
¿Debe el actor informar al

¿Debe el sistema informar al
sistema de cambios externos
actor de cambios internos?
ocurridos?
Diagrama de Casos de Usos
Usado para
compartir
comportamiento
común entre varios
casos de uso
Usado para
modelar por
separado el
Usado para comportamiento
modelar excepcional (o
relaciones de adicional) del
Generalización / caso de uso base
Especialización
entre casos de
uso
Tipos de Actores
Un actor representa un conjunto coherente de roles

que juegan los usuarios de los casos de uso al
interaccionar con el sistema.
• Roles jugados por personas

• Dispositivos
• Otros sistemas.
• El tiempo puede ser un actor
59
Actores
• Un usuario puede jugar diferentes roles.

• En la realización de un caso de uso pueden intervenir
diferentes actores.
• Un actor puede intervenir en varios casos de uso.
• Identificar casos de uso mediante actores y eventos
externos.
• Un actor necesita el caso de uso y/o participa en él.
60
Actores
Dos tipos de actores:
• Principal:
Requiere al sistema el cumplimiento de un
objetivo.
• Secundarios:
El sistema necesita de ellos para satisfacer
un objetivo.
61
Propiedades de los casos de uso
1. Son iniciados por un actor con un objetivo en mente y es

completado con éxito cuando el sistema lo satisface.
2. Puede incluir secuencias alternativas que llevan al éxito
y fracaso en la consecución del objetivo.
3. El sistema es considerado como una “caja negra” y las
interacciones se perciben desde fuera.
4. El conjunto completo de casos de uso especifica todas
las posibles formas de usar el sistema, esto es el
comportamiento requerido.
62
Descripción de un caso de uso
• Son documentos de texto, no son diagramas.

• El modelado de casos de uso consiste en escribir texto,
no en dibujar diagramas.
• Describir el flujo de eventos
• Texto estructurado informal
• Texto estructurado formal (plantillas)
• Pseudocódigo
• Notaciones gráficas: diagramas de secuencia
• Debe ser legible y comprensible para un usuario no experto.
• Debe indicar: actores, flujos principal y excepcionales.
63
Descripción Textual de los Actores del Sistema
Nombre: <nombre del actor>

Descripción:
<descripción del actor>
Nombre: Usuario no Autenticado

Descripción:
Representa a un usuario que no se a identificado frente

al sistema. Generalmente estos usuarios deberían
poder registrarse (crear un nuevo usuario) o ingresar al
sistema para transformarse en usuarios autenticados,
en moderadores o en administradores del sistema

...
Descripción Textual de un Caso de Uso
Nombre: <nombre del caso de uso>

Autor: <nombre del autor (o autores) del caso de uso>
Fecha: <fecha de creación del caso de uso>
Descripción:
<breve descripción del caso de uso>
Actores:
<actores participantes en el caso de uso>
Precondiciones:
<condiciones que deben cumplirse para poder ejecutar el caso de uso>
Flujo Normal:
<flujo normal (feliz) de ejecución del caso de uso>
Flujo Alternativo:
<flujos alternativos de ejecución del caso de uso>
Poscondiciones:
<condiciones que deben cumplirse al finalizar la ejecución del caso de uso>

Planillas de Casos
de Uso (Generales)
Nombre: Crear mensaje foro

Autor: Pedro Pérez
Fecha: 21/04/09
Descripción:
Permite crear un nuevo mensaje (hilo) en el foro de discusión.
Actores:
Usuario / Moderador
Precondiciones:
El usuario debe de estar autenticado en el sistema.

...continuación
Flujo Normal:
1.- El actor pulsa sobre el botón para crear un nuevo mensaje.
2.- El sistema muestra una caja de texto para introducir el título del
mensaje y una zona de mayor tamaño para introducir el cuerpo del
mensaje.
3.- El actor introduce el título del mensaje y el cuerpo del mismo.
4.- El sistema comprueba la validez de los datos y los almacena.
5.- El moderador recibe una notificación de que hay un nuevo mensaje.
6.- El moderador acepta y el sistema publica el mensaje si éste fue
aceptado por el moderador.
Flujo Alternativo:
4.A.- El sistema comprueba la validez de los datos, si los datos no son
correctos, se avisa al actor de ello permitiéndole que los corrija.
7.B.- El moderador rechaza el mensaje, de modo que no es publicado sino

devuelto al usuario.
Poscondiciones:
El mensaje ha sido almacenado en el sistema y fue publicado.
Descripción de un caso de uso: textual
Realizar Venta (en un Terminal de Punto de Venta o TPV)
Actor Principal: Cajero

Flujo Principal: Un cliente llega al TPV con un conjunto de artículos. El
Cajero registra los artículos y se genera un ticket. El cliente paga en efectivo
y recoge los artículos.
1. El cliente llega al TPV con los artículos.

2. El cajero registra el identificador de cada artículo.
3. El sistema obtiene el precio de cada artículo y añade la información a la
transacción de venta.
4. Al acabar el cajero indica la finalización de la introducción de artículos.
68
Reglas de Estilo -Diagramas de Casos de Uso)
• Cada actor y caso de uso debe tener un nombre único
• Los actores deben tener nombres y/o iconos

representativos. Los nombres de los actores deben
representar roles
• El nombre de un caso de uso debe indicar acción y

debe ser claro y conciso
• Forma General: Verbo (Infinitivo) + Predicado
Reporte de
Ventas

Reglas de Estilo -Diagramas de CU
• Mantener todos los casos de uso de un

diagrama al mismo nivel de abstracción
• Evitar el cruce de líneas
• Evite tener demasiados casos de uso en el

mismo diagrama .
• Evite el uso complejo de relaciones de

extensión, especialización e inclusión (No más
de tres niveles)

Reglas de Estilo-Para la Descripción Textual de CU
• Narrar el flujo de eventos usando voz activa,

en tiempo presente y desde la perspectiva
del actor:
Evitar el uso de la voz pasiva:

“La clave es introducida por el usuario”
Preferir la voz activa:

“El usuario introduce la clave”
“El sistema valida la clave”
Reglas de Estilo-Para la Descripción Textual de CU
• Exprese cada paso del flujo usando la forma

llamada y respuesta:
“El actor introduce su nombre de usuario y su
contraseña, y el sistema verifica si los datos
concuerdan con lo que está almacenado en la
base de datos”
• El caso de uso que se describe debe expresar un

solo requisito funcional
• Sin embargo, un caso de uso puede expresar

más de un requisito NO funcional

Ejemplo : DCU

CU y Colaboraciones
• Con un caso de uso se describe un comportamiento

esperado del sistema, pero no se especifica cómo
se implementa.
• Una caso de uso se implementa a través de una
colaboración:
“Sociedad de clases y otros elementos que
colaborarán para realizar el comportamiento
expresado en un caso de uso”
• Una colaboración tiene una parte estática
(diagramas de clases) y una parte dinámica
(diagramas de secuencia).
74
Descripción de un caso de uso: gráfica
Realizar Venta
Diagrama de secuencia
:Sistema
: Cajero
crearNuevaVenta()
* introducirItem(cod,cantidad)
finalizarVenta()
hacerPago(cantidad)
75
Casos de uso y Colaboraciones
caso de uso
colaboración
Hacer Pedido
Gestión Pedidos
realización
76
Estereotipos

Generalización
• La herencia indica que un objeto tiene desde el momento

de su creación, acceso a todas las propiedades de otra
clase.
• Esto mismo se aplica a los actores y a los Casos de Uso,
se conoce como generalización y a veces se especifica
con una relación “es un”
Autorización
Cargo
Autorización
Cargo con
Aviso al celular

Organización de Casos de uso
 Tres tipos de relaciones:

• Generalización
 Un cdu hereda el comportamiento y significado de otro.
• Inclusión
 Un cdu base incorpora explícitamente el comportamiento de
otro en algún lugar de su secuencia.
• Extensión
 Un cdu base incorpora implícitamente el comportamiento de
otro cdu en el lugar especificado indirectamente por este otro
cdu.
79
Ejemplo
Extensión
«extend»
Hacer Pedido
Hacer Pedido Urgente
(establecer
prioridad)
«include»
Comprobar clave
Inclusión
Validar Usuario
Generalización
«include»
Seguir Pedido Examinar retina
80
Ejemplo: Include
Algunas personas utilizan la

inclusión para expresar que
el caso de uso asociado
debe de invocarse de
manera “obligatoria”
Múltiples casos de uso “reutilizan” otros

casos de uso. De esta forma no es necesario
describir varias veces el mismo caso de uso
incluido
Ejemplo : Extend
Puntos de extensión
explícitos
Puntos de extensión
explícitos

Ejemplo: Notas
Las notas son un elemento
común de UML, se pueden
asociar a casi todos elementos
disponibles de UML
Una extensión puede estar asociada

a varios puntos de extensión
Relación de inclusión
• Permite factorizar un comportamiento en un caso de uso

aparte y evitar repetir un mismo flujo en diferentes casos de
uso.
• Ejemplo:
Hacer Pedido:
Obtener y verificar el número de pedido;
Incluir “Validar usuario”;
Recoger los ítem del pedido del usuario;
…

Relación de extensión
• El caso de uso base incluye una serie de puntos de

extensión.
• Sirve para modelar:

• la parte opcional del sistema, o
• un subflujo que sólo se ejecuta bajo ciertas
condiciones.

Relación de extensión
• Ejemplo:
Hacer Pedido:
Incluir “Validar usuario”;
Recoger los ítem del pedido del
usuario;
Establecer prioridad: punto de
extensión
Enviar pedido para ser procesado
según la prioridad.

Obtención de casos de uso
• Identificar los usuarios del sistema.
• Encontrar todos los roles que juegan los usuarios y
que son relevantes al sistema.
• Para cada rol identificar todas las formas de
interactuar con el sistema.
• Crea un caso de uso por cada objetivo.
• Estructurar los casos de uso.
• Revisar y validar con el usuario.

Plantilla usecases.org (Larman)
• Resumen
• Actores Principales y Secundarios
• Personas involucradas e Intereses
• Precondiciones
• Poscondiciones
• Escenario Principal (Flujo Básico)
• Extensiones (Flujos Alternativos)
• Requisitos de Interfaz de Usuario
• Requisitos No-Funcionales
• Cuestiones Pendientes
88
Granularidad
• Diferente granularidad
• Casos de uso del negocio
• Procesos de Negocio: Objetivo estratégico de la empresa
• Ej. Vender productos
• Casos de uso del sistema

• Objetivo de un usuario
• Ej. Realizar una compra
• Casos de uso de inclusión

• Forman parte de otro, son como subfunciones
• Ej. Buscar, Validar, Login
89
Recomendaciones
• Especificar casos de uso no es una actividad de

dibujar diagramas sino de escribir con el detalle
necesario el flujo principal y los flujos alternativos:
“centrado en la escritura en vez del dibujo”.
• No hay que preocuparse demasiado por las
relaciones entre casos de uso ni entre actores.
• El objetivo inicial es identificar los actores y a
partir de sus objetivos encontrar los casos de uso,
ya que el diagrama de casos de uso es una ayuda
visual.
• Los actores deben interactuar con el sistema.
90
Recomendaciones
• No incluir como caso de uso las operaciones CRUD

sobre un objeto de negocio (alta, consulta, borrado,
actualización).
• La excepción es si se trata de operaciones relevantes
para el sistema, como “Registrar Cliente” en un
sistema de venta por Internet.
• Cuidado con el empleo de la relación “include”.
¡No Hacer Una Descomposicion Funcional!
• Los casos de uso sólo consideran los requisitos
funcionales del proyecto, hay que añadir los no-
funcionales.
91

Semana 4 El Modelo de Diseño 2019.1 PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Semana 4 El Modelo de Diseño 2019.1 PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

EL MODELO DEL DISEÑO

Universidad Nacional Mayor de San Marcos © NMC

Es un proceso de ingeniería del software que agrupa las 6 mejores prácticas

Universidad Nacional Mayor de San Marcos

Pieza de información utilizada o producida por un proceso de

Artefactos implicados durante la captura de requisitos

• Modelo de Casos de Uso

• Prototipo de Interfaz de Usuario

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Encontrar Actores Estructurar el Modelo

Universidad Nacional Mayor de San Marcos

Ofrecer una especificación más precisa de los requisitos que la

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Planificar Diseñar prueba Evaluar prueba

Ingeniero de pruebas Realizar Prueba

Ingeniero de pruebas Realizar prueba

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Objetivo: Establece la viabilidad del proyecto

Modelo Casos de uso Casos de uso Casos de uso Casos de uso

Fase Cerca del >80% 40% - 80% 20% - 40% <10%

Fase 100% 100% 100% 100% si se 100%

Universidad Nacional Mayor de San Marcos

Objetivos: Elaborar una arquitectura estable, Conocer

Universidad Nacional Mayor de San Marcos

Objetivo: La capacidad de operación inicial.

Hito : Funcionalidad operativa

Universidad Nacional Mayor de San Marcos

• Objetivos: Despliegue del producto en el cliente

Hito : Release del producto

Universidad Nacional Mayor de San Marcos

El Rational Unified Process fue el resultado de una convergencia de

Universidad Nacional Mayor de San Marcos

Con RUP, un proceso de desarrollo es representado usando un conjunto de

Elementos Básicos De RUP

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

vocabulario, ensamblado del

Funcionamiento, topología del

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

• El modelo de diseño puede verse en dos dimensiones

• La dimensión del proceso: la cual indica la evolución del diseño

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

• El diseño de datos (algunas veces llamado arquitectura de

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

• Importancia de la estructura de datos

Universidad Nacional Mayor de San Marcos

• El diseño arquitectónico para el SW es como el plano de

Universidad Nacional Mayor de San Marcos

• El diseño de interfaz parar SW es el equivalente a un

Universidad Nacional Mayor de San Marcos

• Elementos importantes del diseño:

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

• El diseño de las interfaces externas requiere información

Las realizaciones del diseño de clases de análisis representan todas las