Desarrollo de un sistema con rup uml

Lic. Marisol Mendez Cope
El Alto, Octubre de 2015
INSTITUTO TECNICO COMERCIAL
INCOS EL – ALTO
CARRERA: ANALISIS DE SISTEMAS

¿POR QUÉ MODELAR EL NEGOCIO ANTES DE
MODELAR EL SISTEMA?
 El sistema a desarrollar administrará la
información que pertenece al negocio.
 El sistema será utilizado en
organizaciones que ejecutan procesos
del negocio cada vez más
automatizables
 El sistema se adoptará al entorno de la
organización.

¿POR QUÉ MODELAR EL NEGOCIO ANTES DE
MODELAR EL SISTEMA?
 Porque desde la
perspectiva de los
sistemas no es posible
automatizar procesos
que no estén
claramente definidos.
 Para identificar con
facilidad donde están
sus problemas u
oportunidades de
crecimiento y mejora.

CONCEPTOS FUNDAMENTALES PARA
MODELAR NEGOCIOS
LA EMPRESAY
SUS PROCESOS
¿Cuáles son y a
quienes están
dirigidos?
¿Cuáles son sus
resultados?
¿Cuáles son las
tareas que se
deben llevar a
cabo?

CONCEPTOS FUNDAMENTALES PARA
MODELAR NEGOCIOS

MODELADO DE NEGOCIO
en el Ciclo deVida de RUP

PROPOSITO DEL MODELADO DEL
NEGOCIO
1. Entender la estructura y la dinámica de la
organización.
2. Entender los problemas actuales e
identificar el campo de acción y sus mejoras
potenciales.
3. Evaluar el impacto del cambio de la
organización.
4. Asegurarse de que los clientes, usuarios
finales y desarrolladores tienen una idea
común de la organización.
5. Preliminarmente obtener los requerimientos
del sistema.

¿ EN QUE CONSISTE EL MODELADO
DE NEGOCIO ?
 Se lo realiza en la primera fase de la
metodología RUP - Fase de Inicio.
 Consiste en tener un conocimiento
preciso de lo que actualmente se hace
en los procesos que serán
considerados en el nuevo sistema.

ACTIVIDADES DEL MODELADO DE
NEGOCIO
1. Tener una visión general de la empresa o
institución en la que se desarrollará el sistema
de información, para ello:
 Identificar el rubro,
 Número de empleados,
 Áreas de la empresa,
 Número de sucursales,
 Ubicación de las sucursales,
 Áreas involucradas directamente en el sistema,
 Áreas que se servirán a futuro del sistema de
información,
 Estructura organizacional de la empresa, etc.

NEGOCIO
2. En el área o áreas directamente
relacionadas al sistema:
 Identificar y describir los procesos
correspondientes,
 Identificar los usuarios responsables,
 Definir el flujo de los procesos y de la
información.
• Esto nos da una idea de la complejidad de
los procesos, del número de áreas o
usuarios involucrados.

NEGOCIO
3. Determinar el volumen de la información
manejada a través del número de
transacciones/mes del sistema actual.
Esto nos da una idea de los
requerimientos de hardware y software
para la base de datos, de las conexiones
de red, de los requerimientos de
comunicación - internet, el
dimensionamiento del servidor,
equipamiento de PC's, etc.

NEGOCIO
4. Identificar las ventajas y desventajas y
posibles mejoras que los mismos
usuarios ven en sus procesos actuales.
Esto es importante para considerar los
cambios al momento de diseñar el nuevo
sistema.
5. La información obtenida en ésta fase, al
responsable del proyecto informático, le
permite: Identificar los subsistemas o
módulos (componentes) del Sistema a
desarrollar.

NEGOCIO
6. Conformar el equipo de desarrollo
informático, que dependiendo del
tamaño del sistema podrán ser 2, 3, 4,
equipos de trabajo, cada uno con sus
analistas y programadores asignados.
Para ello también se toma en cuenta el
tiempo requerido por la empresa para
la conclusión del proyecto.

HERRAMIENTAS PARA EL
MODELADO DE NEGOCIO
 Las herramientas que se aplican en ésta etapa
son:
 Casos de uso de alto nivel (CUAN)
 Diagramas de casos de uso (DCU)
 Diagrama de actividades (DA)
 Diagrama de objetos del negocio (DO)
El modelado de negocio también abarca la fase de
Elaboración, en las actividades relativas al análisis
funcional del sistema, pero no con la intensidad
que se da en la fase de Inicio.

ROLES QUE SE CUMPLEN
EN EL MODELADO DE NEGOCIO

HERRAMIENTAS EMPLEADAS POR ACTIVIDAD
EN EL MODELADO DE NEGOCIO
1. Evaluar la organización.
2. Encontrar los actores y casos de uso del
negocio. (Con CUAN y DCU)
3. Construir el modelo de casos de uso del
4. Encontrar los trabajadores y casos de uso del
5. Detallar los casos de uso del negocio. (Con DA)
6. Construir el modelo de análisis del negocio.
(Con DO)
7. Mantener las reglas del negocio.
8. Capturar un vocabulario común (glosario).
9. Definir las actividades a automatizar.

ESTRUCTURA DEL
MODELADO DEL NEGOCIO
A) Modelo de Casos de
Uso del Negocio
 Descripción de Casos de Uso
de Alto Nivel (CUAN)
 Diagramas de Casos de uso
(DCU)
Diagramas de Actividades
(DA) (por cada caso de uso de
alto nivel)
B) Modelo de
Objetos del
Negocio
 Diagrama de
Objetos del
negocio (DO)

ESTEREOTIPOS EMPLEADOS EN EL
(Enterprise ArchitectV.7)
 Un estereotipo representa la subclasificación de un
elemento del modelo.
 Un estereotipo puede tener su propio icono.
DIAGRAMA DE CASOS DE USO DIAGRAMA DE OBJETOS

ESTEREOTIPOS EMPLEADOS EN EL
Identificar trabajadores del negocio
 Un trabajador de negocio (business
worker) representa un rol jugado por
alguien o algo dentro del negocio,
realiza alguna actividad dentro del
mismo.
 Un business worker:
 Trabaja en una unidad organizacional.
 Interactúa con otros business workers o
bussiness actors.
 Manipula entidades del negocio.

A) MODELO DE CASOS DE USO
DEL NEGOCIO
 Describe los procesos de negocios de
una empresa en términos de:

ARTEFACTOS DEL MODELO DE
CASOS DE USO DEL NEGOCIO
A) Modelo de Casos
de Uso del Negocio
A1) Casos de Uso de
Alto Nivel
A2) Diagramas
de Casos de uso
A3) Diagramas
de Actividades

A1) CASOS DE USO DE ALTO NIVEL
 Un caso de uso de alto nivel, describe un proceso muy
brevemente, casi siempre en dos o tres enunciados.
Conviene servirse de este tipo de caso durante el examen
inicial de los requerimientos y del proyecto, a fin de obtener
rápidamente el flujo de información en cada uno de los
procesos o tareas que se realizan en el negocio.
 Su formato es:
Caso de uso Nombre del Caso de Uso (en términos de
acción)
Actores Que participan en el proceso descrito
Tipo Primario o Secundario
Descripción Narración del proceso de forma breve y
concreta

 Un caso de uso debe ser simple, inteligible, claro
y conciso.
 Generalmente hay pocos actores asociados a
cada Caso de Uso.
 Preguntas clave:
1. ¿cuáles son las tareas del actor?
2. ¿qué información crea, guarda, modifica,
destruye o lee el actor?
3. ¿debe el actor notificar al sistema los
cambios externos?
4. ¿debe el sistema informar al actor de los
cambios internos?

EJEMPLO: SISTEMA BIBLIOTECARO
CASO DE USO DE ALTO NIVEL PARA EL PROCESO “PRESTAR LIBRO”
CASO DE USO PRESTAR LIBRO
ACTOR Bibliotecario, Lector
TIPO Primario
DESCRIPCION Este caso de uso comienza cuando un lector
requiere prestarse un libro determinado,
solicita su préstamo al bibliotecario indicándole
el titulo y/o autor del libro. El bibliotecario
realiza primero la búsqueda en los estantes por
el título, sino lo encuentra realiza la búsqueda
por autor. Una vez que el bibliotecario
encuentra el libro le proporciona una ficha de
préstamo al lector, quien llena sus datos y los
del libro que se esta prestando, una vez llenada
la ficha la entrega al bibliotecario junto con su
C.I. y/o carnet de lector, y se lleva el libro.

A2) DIAGRAMAS DE CASOS DE USO
 Explica gráficamente un conjunto de casos de uso
de un sistema, los actores y la relación entre éstos y
los casos de uso.
 Los casos de uso se muestran en óvalos y los
actores son figuras estilizadas, existen líneas de
comunicaciones entre los casos y los actores; las
flechas indican el flujo de la información o el
estímulo.
 Tiene por objeto ofrecer una clase de diagrama
contextual que nos permite conocer rápidamente los
actores externos de un sistema y las formas básicas
en que lo utilizan.

A2) DIAGRAMAS DE CASOS DE USO
 Son útiles en tres áreas:
• Nuevos casos de uso por lo general generan
nuevos requerimientos mientras el sistema es
analizado y diseñado.
• Describen que es lo que hace un sistema
desde un punto de vista externo
(contexto)haciendo énfasis en qué es lo que
hace en lugar del cómo lo hace.
1. Determinación
de
Requerimientos
• Su notable simplicidad en representación, hace
que los diagramas de casos de uso sean la
mejor herramienta de comunicación entre los
desarrolladores y los clientes.
2. Comunicación
con clientes
• Una colección de escenarios para un caso de
uso genera un conjunto de simulaciones de
casos para cada posible escenario.
3. Simulación de
posibles
escenarios

EJEMPLO
DIAGRAMA PARA EL CASO DE USO DE ALTO
NIVEL :“Vender Productos” en una Farmacia
 Varios casos de uso, están conectados a escenarios, un
escenario es un ejemplo de qué es lo que sucede en el
negocio (sistema actual).
Registra los datos de la
venta en un cuaderno
Paga o entrega el
cambio del pago de
los medicamentos
Vende medicamentos

A2) DIAGRAMA DE CASOS DE USO

Ejemplo de Diagrama de Casos de Uso del Negocio
en Enterprise ArchitectV.7

A3) DIAGRAMA DE ACTIVIDADES
 Un diagrama de actividades representa
el comportamiento interno de una
operación o de un caso de uso, bajo la
forma de un desarrollo por etapas,
agrupadas secuencialmente.
 Propósito: “Modelar el flujo de tareas” y
“Modelar las operaciones”

 Los diagramas de actividades ayudan a
describir el detalle de lo que pasa dentro
del negocio, y para ello se examinan los
roles específicos que juegan las personas
(TRABAJADORES DEL NEGOCIO) y las
ACTIVIDADES que realizan.
 Los Diagramas de actividades ayudan a
identificar que funciones deberá asumir el
producto software y quienes serán los
actores del futuro sistema.

Elementos Básicos
Estados de actividad y estados
de acción
 La representación de ambos es un rectángulo con
las puntas redondeadas, en cuyo interior se
representa una actividad o una acción.
 “Un estado que represente una acción es atómico,
lo que significa que su ejecución se puede
considerar instantánea y no puede ser
interrumpida”. Ejemplo:

Transiciones
 Reflejan el paso de un
estado a otro, bien sea de
actividad o de acción. Esta
transición se produce
como resultado de la
finalización del estado del
que parte el arco dirigido
que marca la transición.
 Como todo flujo de control
debe empezar y terminar
en algún momento se
indica esto utilizando dos
disparadores de inicio y
fin.
Elementos Básicos

División y unión
 Existen algunos casos
en los que se requieren
tareas concurrentes.
 El proceso de división,
representa la
concurrencia, y el
momento de la unión de
nuevo al flujo de control
secuencial por una línea
horizontal ancha.
Elementos Básicos

Calles
 Cuando se modelan
flujos de trabajo de
organizaciones, es
especialmente útil
dividir los estados de
actividades en grupos,
cada grupo tiene un
nombre concreto y se
denominan calles.
 Cada calle representa
a la parte de la
organización
responsable de las
actividades que
aparecen en esa calle.
Elementos Básicos

Elementos Básicos

Caso de Uso del negocio: Solicitar Cotización de materiales
Ejemplo UNO

Caso de Uso del negocio: Solicitar Cotización de materiales

Ejemplo DOS

EjemploTRES

Diagrama de Actividades:
Solicitar Cotización de materiales
Ejemplo de Diagrama de Actividades
en Enterprise ArchitectV.7

B) MODELO DE OBJETOS DEL NEGOCIO
 El Modelo de Objetos del Negocio identifica todos
los “ROLES” y “COSAS” en el negocio, los cuales
son representados como clases en la Vista Lógica.
 Existen dos tipos diferentes de objetos en el
modelo de negocio:

Elementos

De los diagramas de
actividades

Ejemplo

Ejemplo del Modelo de Objetos en
Enterprise ArchitectV.7

¿COMO IDENTIFICAR LOS CASOS DE
USO DEL SISTEMAY LOS ACTORES DEL
SISTEMA?

¿COMO IDENTIFICAR LOS
CASOS DE USO DEL SISTEMA?
Comenzar con los trabajadores del negocio. Para
cada uno:
1. Decidir si el trabajador del negocio va a utilizar el
sistema de información.
2. De ser así identificar un actor en el Modelo de Casos
de Uso del sistema.
3. Para cada caso de uso del negocio en el que participe
el trabajador del negocio, crear un caso de uso del
sistema.
4. Repetir éstos pasos para todos los trabajadores del
negocio.

1° Partimos del Diagrama de Casos de Uso
del Negocio
Como identificar los Casos de
Uso del Sistema

Uso del Sistema
2° Analizamos el Modelo de Objetos

Uso del Sistema

Percepciones de un Proyecto de
Software

MODELADO DEL SISTEMA
FLUJO DETRABAJO DE RUP

ESTRUCTURA DEL
MODELADO DEL SISTEMA
1. IDENTIFICACION DE
REQUERIMIENTOS
2. ANALISIS
3. DISEÑO

FLUJO DETRABAJO DE
REQUERIMIENTOS
A) REQUERIMIENTO
FUNCIONAL
B) REQUERIMIENTO
NO FUNCIONAL
“Una capacidad o
condición que el
sistema cumplirá”
“Propiedades o
cualidades que el
producto software debe
tener”

A) REQUERIMIENTOS FUNCIONALES
 Las funciones del sistema son lo que éste habrá de hacer,
en base a las funciones o actividades que se realizan en el
sistema actual en estudio (o los procesos que se realizan en
la empresa o negocio). Hay que identificarlas y listarlas en
grupos cohesivos y lógicos (módulos).
 Con el objeto de verificar que algún X es de verdad una
función del sistema, la siguiente oración deberá tener
sentido:
“El sistema deberá hacer <X>”
 Por ejemplo:
“El sistema deberá <actualizar la cantidad
de productos vendidos>”

Identificación de Requerimientos
Funcionales a partir del MODELO DEL
NEGOCIO
Descripción Textual de Casos de Uso de Alto Nivel
 Diagramas de Casos de uso
Diagramas de Actividades
Modelo de Objetos
De la realización de:
“Se escogen actividades que serán
automatizadas”

EJEMPLO de Requerimientos
Funcionales
1. Registrar Solicitud
2. Asignar automáticamente código a
una solicitud
3. Asignar solicitud a un pedido.
4. Registrar información de cotización.

Funcionales
 Las funciones básicas o actividades
básicas (relacionadas con el control de
Inventario de productos) que se desarrollan
en el Sistema actual de una Farmacia son
los siguientes:
 Pedido de productos farmacéuticos
 Compra de productos farmacéuticos
 Venta de productos farmacéuticos
 Registro de Inventario de productos farmacéuticos

Funcionales
 Los siguientes son ejemplos de
Requerimientos Funcionales del
sistema en la aplicación del Control de
Inventarios de productos
farmacéuticos en una Farmacia (son
una muestra representativa).

Funcionales
 La lista de requerimientos se lo debe realizar a
partir de los problemas identificados. En el caso
del sistema en la aplicación del Control de
Inventarios de productos farmacéuticos en una
Farmacia, el problema principal a resolver podría
ser:
“ En La Farmacia “Los Olivos”, la forma actual de llevar el registro
y control de las compras, ventas e inventario de los productos
farmacéuticos produce errores de legibilidad, redundancia y cálculos
monetarios, lo que genera pérdida de dinero , clientes y una mala
toma de decisiones por parte del dueño de la Farmacia”.

Funcionales
Funciones Generales
Ref.# FUNCION
RF1.1 El farmacéutico o auxiliar introduce su password para poder utilizar el sistema con
seguridad.
RF1.2 El farmacéutico o auxiliar introduce información del producto a buscar (nombre,
laboratorio, código )
RF1.3 El sistema deberá buscar información requerida del producto a vender
RF1.4 El sistema deberá mostrar información requerida del producto a vender
RF1.5 El sistema deberá capturar información del producto a vender mediante el código del
mismo
RF1.6 El farmacéutico o auxiliar introduce información de la venta efectivizada.
RF1.7 El sistema deberá reducir las cantidades del inventario cuando se realiza una venta
RF1.8 El farmacéutico realiza consultas sobre el stock existente a la fecha actual
RF1.9 El sistema deberá buscar información sobre la consulta realizada
RF1.10 El sistema deberá mostrar en pantalla la información requerida por la consulta
RF1.11 El farmacéutico o auxiliar introduce datos de pedido a realizar
RF1.12 El sistema deberá capturar los datos del pedido a realizar
RF1.13 El farmacéutico introduce datos de la compra de productos a los proveedores
RF1.14 El sistema deberá actualizar el stock de productos cuando se realiza una compra
RF1.15 El sistema deberá mostrar la descripción y el precio del producto registrado
RF1.16 El sistema deberá ofrecer mecanismos de control entre los procesos de compra y venta
RF1.17 El sistema deberá ofrecer un mecanismo de almacenamiento continuo

Funcionales
Funciones de Pedido
Ref.# FUNCION
RF2.1 El farmacéutico maneja los registros de inventario, para generar el informe respectivo
del día.
RF2.2 El sistema deberá capturar la información del informe generado
RF2.3 El sistema deberá mostrar información del informe requerido
RF2.4 El farmacéutico maneja los registros de proveedores y pedidos, para elaborar el pedido
correspondiente
RF2.5 El sistema deberá registrar los datos del pedido realizado.
RF2.6 El sistema deberá ofrecer mecanismos de control entre los procesos

Funcionales
Funciones de Compra
Ref.# FUNCION
RF3.1 El farmacéutico maneja los registros de inventario, para generar el
informe respectivo del día.
RF3.2 El sistema deberá capturar la información del informe generado
RF3.4 El farmacéutico maneja los registros de proveedores y pedidos, para
elaborar el pedido correspondiente
RF3.5 El sistema deberá registrar los datos del pedido realizado.
RF3.6 El sistema deberá ofrecer mecanismos de control entre los procesos

Funcionales
Funciones de Venta
Ref.# FUNCION
RF4.1 El farmacéutico o auxiliar maneja los registros de productos y de
inventario, para verificar la existencia o no de un producto requerido
RF4.2 El sistema deberá buscar la información del producto buscado
RF4.3 El sistema deberá mostrar la información requerida del producto buscado
(la descripción y el precio del producto)
RF4.4 El farmacéutico o auxiliar introduce datos de la venta realizada
RF4.5 El sistema deberá calcular el total de la venta actual (se incluye el
impuesto)
RF4.6 El sistema deberá mostrar el total de la venta
RF4.7 El sistema deberá reducir las cantidades del inventario cuando se realiza
una venta

Funcionales
Funciones de Inventario
Ref.# FUNCION
RF5.1 El Farmacéutico maneja los registros de ventas, pedidos y compras,
para elaborar el informe respectivo.
RF5.2 El sistema deberá capturar información del informe generado
RF5.4 El Farmacéutico imprime información del informe requerido para
apoyo en la toma de decisiones.

Propiedades o cualidades que el producto
software debe tener en relación a:
1. Apariencia o interfaz externa.
2. Usabilidad
3. Rendimiento
4. Soporte
5. Portabilidad
6. Legales
7. Políticas Culturales
B) REQUERIMIENTOS NO FUNCIONALES

B) REQUERIMIENTOS NO FUNCIONALES
8. Confiabilidad
9. Interfaz interna
10. Ayuda y documentación en línea
11. Seguridad
12. Software
13. Hardware
14. Restricciones en el diseño y la
implementación

NO Funcionales
“La interfaz del sistema debe ser
a través de una página Web,
personalizada de acuerdo al
tipo de usuario que acceda al
sistema ”

NO Funcionales
Ref.# FUNCION
RNF1 Permitir la realización de copias de seguridad en dispositivos de
almacenamiento masivo periódicamente.
RNF2 Las interfaces de comunicación con el usuario deben estar en un entorno
gráfico y amigable.
RNF3 Utilizar en los iconos de comando los estándares utilizados en la empresa para
otros sistemas.
RNF4 El sistema debe estar desarrollado en una plataforma Windows de fácil
manejo para los usuarios.
RNF5 Se debe identificar varios niveles de acceso al sistema con roles diferentes de
opciones, estos roles deben ser controlados por un administrador del sistema.
RNF6 El software a ser desarrollado debe contener las características de las normas
de calidad y seguridad utilizadas en la empresa.
RNF7 El ambiente de trabajo debe ser orientado a una tecnología cliente servidor,
debido a que su uso será de departamentos específicos de la empresa.
RNF8 Se deberá tener un curso de capacitación en el uso y administración del
sistema.

ARTEFACTOS PARA EL ANALISIS
2. ANALISIS
A) Definición de Actores
del sistema
B) Casos de uso de alto
nivel del sistema
D) Diagramas de Casos de
uso expandido
C) Casos de uso expandido
del sistema

A) DEFINICION DE ACTORES
Del Sistema a Automatizar
ACTOR CASOS DE USO CON LOS QUE SE RELACIONA
FARMACEUTICO Registra los productos faltantes.
Registra los Pedidos a los Proveedores
Compra Productos al contado
Compra Productos a Crédito
Elabora el inventario de los productos cada cierto periodo de
tiempo.
Vende productos en la Farmacia.
Elabora Factura de venta para los clientes
Ajusta los egresos e ingresos de la Farmacia.
AUXILIAR Realiza la búsqueda de productos en la Farmacia
Vende productos en la farmacia
Registra egresos e ingresos diariamente.

B) CASOS DE USO DE ALTO NIVEL
 El caso de uso es un documento narrativo que describe la
secuencia de eventos de un actor (agente externo) que utiliza un
sistema para completar en proceso.
 Los casos de uso son historias o casos de utilización de un
sistema; no son exactamente los requerimientos ni las
especificaciones funcionales, sino que ejemplifican e incluyen
tácitamente los requerimientos de las historias que narran.
 El caso de uso de alto nivel describe un proceso muy
brevemente, en dos o tres enunciados. Utilizarlo en el examen
inicial de los requerimientos del proyecto.
 En su formato se contempla:
CASO DE USO:
ACTORES:
TIPO:
DESCRIPCION

IDENTIFICACIÓN DE LOS CASOS DE USO
 La identificación de los casos de uso requieren una lluvia de
ideas y revisar los documentos actuales sobre la
especificación de los requerimientos.
METODO 1: Se basa en los Actores
 Se identifican los actores relacionados con un sistema o
empresa.
 En cada actor, se identifican los procesos que inician o en
que participan
METODO 2: Se basa en los Eventos
 Se identifican los eventos externos a los que un sistema ha
de responder.
 Se relacionan los eventos con los actores y con los casos de
uso.

CASOS DE USO PRIMARIOS:
 Representan los procesos comunes más
importantes, es decir los módulos identificados,
Por ejemplo: Compra de Productos.
CASOS DE USO SECUNDARIOS:
 Representan procesos menores o raros; por
ejemplo: Solicitud de surtir un nuevo producto
farmacéutico.
CASOS DE USO OPCIONALES
 Representan procesos que pueden no abordarse

 El siguiente caso de uso de alto nivel describe clara y
concisamente el proceso de comprar insumos farmacéuticos
en una Farmacia.
CASO DE USO: Comprar productos farmacéuticos
ACTORES: Farmacéutico, Proveedor
TIPO: Primario
DESCRIPCION Este caso de uso comienza cuando el
Farmacéutico previo pedido, recibe del
proveedor, los productos que esta comprando.
El Proveedor entrega los productos pedidos y
previo registro de los mismos en una factura,
cobra el importe. Al terminar la operación, el
farmacéutico recibe la factura y registra la
compra de productos concretada.
EJEMPLO

C) CASOS DE USO EXPANDIDOS
 Un caso de uso expandido, describe un proceso más a fondo que el de alto
nivel.
 La diferencia básica con el caso de uso de alto nivel consiste en que tiene una
sección destinada al curso normal de los eventos, que los describe paso por
paso.
 Durante la fase de especificación de requerimientos, conviene escribir en el
formato expandido los casos mas importantes y de mayor influencia; en
cambio, los menos importantes pueden posponerse hasta el ciclo de
desarrollo en el cual van a ser abordados.
 Incluye una sección destinada al curso normal de los eventos
CASO DE USO:
ACTORES:
PROPÓSITO:
RESUMEN:
TIPO:
REFERENCIAS: CRUZADAS:

CASO DE USO: Comprar productos farmacéuticos
ACTORES: Farmacéutico (iniciador), Proveedor
PROPÓSITO: Registrar una compra y su pago en efectivo.
RESUMEN: El Farmacéutico recibe del proveedor, los productos que esta comprando. El Proveedor
entrega los productos pedidos y previo registro de los mismos para su verificación en una
factura, cobra el importe en efectivo. Al terminar la operación, el farmacéutico recibe la
factura y registra la compra de productos concretada.
TIPO: Primario y esencial.
REFERENCIAS: CRUZADAS: Funciones: RF1.11, RF1.12, RF1.13, RF1.14, RF1.15, RF4.1, RF4.2,
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR
1. Este caso de uso comienza cuando el farmacéutico
recibe los productos pedidos al proveedor.
2. El proveedor entrega los productos uno por uno, los
mismos se encuentran registrados en una factura,
previamente elaborada de acuerdo al pedido que se le
hizo
3. El Proveedor entrega la factura al farmacéutico y
cobra el importe de la misma.
4. El farmacéutico escoge la forma de pago:
1. Si paga en efectivo, véase la sección Pago
en efectivo.
2. Si paga a crédito, véase la sección Pago a
crédito.
RESPUESTA DEL SISTEMA
EJEMPLO

CURSO NORMAL DE LOS EVENTOS (continuación)
ACCION DEL ACTOR
5. El proveedor registra el tipo de pago.
6. El proveedor entrega una factura con el tipo de
pago realizado y se marcha.
7. El farmacéutico registra las características de cada
producto. Si hay varios de una misma categoría, el
farmacéutico también puede registrar la cantidad.
9. Al terminar de introducir los detalles de los
productos, le indica al sistema que se concluyó el
registro del producto.
11. El farmacéutico concluye con el registro de la
compra.
8. Determina el precio del producto e incorpora a la
transacción actual la información correspondiente para la
actualización del inventario.
10. Calcula y muestra en pantalla el total de la compra
realizada.
12. Almacena datos de la compra concretada.
CURSOS ALTERNOS
Línea 7: Introducción de datos de producto. Indica error.
EJEMPLO

SECCION: Pagar en Efectivo
ACCION DEL ACTOR
1. El Farmacéutico da un pago en efectivo –“el
efectivo ofrecido”- posiblemente mayor que el total
de la compra.
2. El proveedor recibe el efectivo ofrecido.
3. El proveedor extrae la diferencia del efectivo
recibido.
4. El proveedor le devuelve el cambio al
farmacéutico.
CURSOS ALTERNOS
Línea 1: El farmacéutico no tiene suficiente efectivo. Puede cancelar o iniciar otro método de pago.
SECCION: Pagar a Crédito
ACCION DEL ACTOR
1. El Farmacéutico comunica su decisión de pagar a
crédito al proveedor.
2. Proveedor autoriza el pago a crédito y calcula las
cuotas a obrar.
3. El Farmacéutico paga la primera cuota en efectivo.
EJEMPLO

D) DIAGRAMAS DE CASOS DE
USO EXPANDIDOS
 Los diagramas de caso de uso muestra la relación entre los actores y
los casos de uso del sistema. Representa la funcionalidad que
representa el sistema en lo que se refiere a su interacción externa.
 Los elementos que pueden aparecer en un diagrama de Casos de
Uso son: Actores, casos de uso y relaciones entre casos de uso.
 Un actor es una entidad externa al sistema que realiza algún tipo de
interacción con el mismo. Se representa mediante una figura humana
dibujada con palotes. Esta representación sirve tanto para actores
que son personas como para otro tipo de actores (otros sistemas,
sensores, etc.).
 Un caso de uso es una descripción de la secuencia de interacciones
que se producen entre un actor y el sistema, cuando el actor usa el
sistema para llevar a cabo una tarea específica. Expresa una unidad
coherente de funcionalidad, y se representa en el Diagrama de Casos
de Uso mediante una elipse con el nombre del caso de uso en su
interior. El nombre del caso de uso debe reflejar la tarea específica
que el actor desea llevar a cabo usando el sistema.

USO EXPANDIDOS
Relaciones de casos de uso
Entre dos casos de uso puede existir las siguientes relaciones:
A)Extend: (Extiende)
Cuando un caso de uso especializa a otro extendiendo su
funcionalidad.
B)Include: (Usa)
Cuando un caso de uso utiliza a otro.

USO EXPANDIDOS
Relaciones de casos de uso
 Se representan como una línea que une a los dos
casos de uso relacionados, con una flecha en
forma de triangulo y con un etiqueta <<extend>> o
<<include>> según sea el tipo de relación.
 En el diagrama de casos de uso se representa
también el sistema como una caja rectangular con
el nombre en su interior. Los casos de uso están
en el interior de la caja del sistema, y los actores
fuera, y cada actor esta unido a los casos de uso
en los que participa mediante una línea.

D) DIAGRAMA DE CASOS DE USO EXPANDIDOS
EJEMPLO
• Diagrama De Casos de Uso para el caso de uso expandido: Vender Productos

D) DIAGRAMA DE CASOS DE USO EN
ENTERPRISE ARCHITECT

ARTEFACTOS PARA EL DISEÑO
3. DISEÑO
A) Diagrama de Secuencia
B) Diagrama de Estados
D) Diagramas de Clases
C) Casos de uso reales

A) DIAGRAMA DE SECUENCIA
 El diagrama de secuencia es uno de los diagramas
más efectivos para modelar interacción entre
objetos en un sistema.
 Un diagrama de secuencia muestra la interacción
de un conjunto de objetos en una aplicación a
través del tiempo y se modela para cada método de
la clase.
 Mientras que el diagrama de casos de uso permite
el modelado de una vista business del escenario, el
diagrama de secuencia contiene detalles de
implementación del escenario, incluyendo los
objetos y clases que se usan para implementar el
escenario, y mensajes intercambiados entre los
objetos.

A) DIAGRAMAS DE SECUENCIA
 Si se tiene modelado la descripción de cada caso de uso
como una secuencia de varios pasos (caso de uso
expandido), entonces se puede "caminar sobre" esos pasos
para descubrir qué objetos son necesarios para que se
puedan seguir los pasos.
 Un diagrama de secuencia muestra los objetos que
intervienen en el escenario con líneas discontinuas verticales,
y los mensajes pasados entre los objetos como flechas
horizontales.

A)Elementos del DIAGRAMAS
DE SECUENCIA
1) Objetos - 2) Foco de control o activación – 3) Mensajes

A)Elementos del DIAGRAMAS
DE SECUENCIA1. Objetos:
Se representan mediante una línea vertical llamada línea de vida, en la
parte superior se coloca un rectángulo con el nombre del objeto o de la
clase, en caso de que el objeto sea destruido antes de terminar el diagrama
se representa la terminación mediante un aspa.
2. Foco de control o activación:
Se representa mediante un rectángulo superpuesto a la línea de vida del
objeto, su tamaño depende de la duración de la acción realizada por el
objeto, la parte superior indica el inicio de la acción, la parte inferior indica la
terminación.
3. Mensajes:
Se representan mediante una línea horizontal entre las líneas de vida de los
objetos que intercambian los mensajes, es posible añadir a los mensajes
condiciones o iteraciones, la condición se representara mediante una
condición booleana entre corchetes, el mensaje será enviado si la condición
es cierta. La iteración se representa mediante un asterisco y una expresión
entre corchetes indicando el numero de veces

¿ Cómo elaborar un
DIAGRAMA DE SECUENCIA?
1°Trazar una línea que represente el sistema como una caja
negra.
2º Identificar los actores que operan directamente sobre el
sistema. Trazar una línea para cada uno de ellos.
3º A partir del curso normal de los eventos del caso de uso
expandido, identificar los eventos (“externos”) del sistema que
son generados por los actores. Mostrarlos gráficamente en el
diagrama.
4º A la izquierda del diagrama puede incluirse o no el texto del
caso de uso.
NOTA: La identificación y ordenamiento de los eventos del
sistema para incluirlos en los diagramas de secuencia se
logran de la revisión de los casos de uso.

¿ Cómo elaborar un DIAGRAMA
DE SECUENCIA?

Ejemplo UNO
 Este diagrama describe
la secuencia
(simplificada) de
mensajes de un sistema
de restaurante.
 El diagrama representa
a un cliente pidiendo
comida y pagando.
 Las líneas punteadas
extendiéndose hacia
abajo indican la línea de
tiempo de cada objeto.
 Las flechas representan
mensajes (estímulos) de
un "actor" u objeto a
otros objetos.

Ejemplo DOS

EjemploTRES

Ejemplo CUATRO

A) DIAGRAMA DE SECUENCIA EN

B) DIAGRAMA DE ESTADO
 Es una manera de caracterizar un cambio en
un sistema, es decir que los objetos que lo
componen modificaron su estado como
respuesta a los sucesos y al tiempo.
 Presenta los estados en los que puede
encontrarse un objeto junto con las
transiciones entre los estados, y muestra los
puntos inicial y final de una secuencia de
cambios de estado.

 Un diagrama de estados puede representar ciclos
continuos o bien una vida finita, en la que hay un
estado inicial de creación y un estado final de
destrucción (del caso de uso o del objeto).
 El estado inicial se muestra como un círculo sólido
y el estado final como un círculo sólido rodeado de
otro círculo.
 En realidad, los estados inicial y final son
pseudoestados, pues un objeto no puede “estar” en
esos estados, pero nos sirven para saber cuáles
son las transiciones inicial y final(es).

Simbología

Simbología
El área superior contendrá el nombre
del estado (se debe establecer haya o
no haya subdivisión).
Las variables de estado como cronómetros
o contadores son indicadores del estado.
Las actividades constan de sucesos y
acciones, tres de las más usadas son:
Entrada, Salida y Hacer.

Simbología - Ejemplo

Simbología
 Una acción de entrada aparece en la forma:
entrada/acción_asociada
donde acción_asociada es el nombre de la acción que se realiza al
entrar en ese estado. Cada vez que se entra al estado por medio de
una transición la acción de entrada se ejecuta.
 Una acción de salida aparece en la forma:
salida/acción_asociada.
Cada vez que se sale del estado por una transición de salida la
acción de salida se ejecuta.
 Una acción interna es una acción que se ejecuta cuando se recibe
un determinado evento en ese estado, pero que no causa una
transición a otro estado. Se indica en la forma:
nombre_de_evento/acción_asociada.

C) DIAGRAMA DE ESTADO
Elementos - Ejemplo

Ejemplo UNO

Ejemplo DOS

Anidados - Paralelos
 Los estados pueden ser anidados. Estos implican
aquellos estados (sub estados) que puedan
existir dentro de un estado total.
 Los estados Paralelos pueden ser también
definidos donde un objeto pueda tener estados
serios al mismo tiempo.
 Por ejemplo: Una persona puede tener en
cualquier momento muchos estados paralelos.
Estos pueden ser: "Caminando", "Pensando",
"Joven", etc.

Ejemplo – Estados anidados

EN ENTERPRISE ARCHITECT

C) CASOS DE USO REAL
 Un caso real de uso, describe concretamente el proceso a partir de su diseño
concreto actual, sujeto a las tecnologías específicas de entrada y salida, etc.
 Cuando se trata de la interfaz para el usuario, a menudo ofrece
presentaciones de pantalla y explica la interacción con los artefactos.
CASO DE USO: ……
ACTORES: ……
PROPOSITO: ……
RESUMEN: ……
TIPO: ……
REFERENCIAS CRUZADAS: ……
Acción del actor Respuesta del sistema
..…… ..….
Cursos alternos
……..
En el caso de Secciones Ver ejemplos

Ejemplo
CASO DE USO: Comprar Productos
ACTORES: Cliente (iniciador), Cajero
PROPOSITO: Capturaruna venta y su pago en efectivo
RESUMEN:
Un Cliente llega a la caja con productos que desea comprar. El
cajero registra los productos de la compra y recibe el pago en
efectivo. Al terminar la transacción, el Cliente se marcha con
los productos comprados.
TIPO: Primario y real.
REFERENCIAS CRUZADAS: Funciones: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1.
1. Este caso de uso comienza cuando
un Cliente llega a la caja TPDV con
objetos que desea comprar.
2. Con cada producto, el Cajero teclea el
código universal de producto (CUP)
en A de la Ventana-1. Si hay más de
un producto, es opcional capturar la
cantidad en E. Se oprime H después
de capturar cada producto.

Ejemplo
4. Al terminar de capturar los productos el
Cajero oprime el botón I para indicarle a la
TPDV que terminó de capturar los
productos.
6. El cajero le indica el total de la venta al
Cliente.
7. El Cliente efectúa un pago.
8. El Cajero gestiona el pago.
10.El Cajero le da al Cliente el recibo
impreso.
11. El Cliente se marcha con los artículos
comprados.
3. Agrega la información sobre el producto a la
actual transacción de ventas. La descripción y el
precio del producto actual se muestran en B y en
F de la ventana-1.
5. Calcula y presenta en C el total de la venta
9. El Sistema registra la venta. Genera un recibo.
Cursos alternos
……..

D) DIAGRAMA DE CLASES
 Un diagrama de diseño de clases describe gráficamente las
especificaciones de las clases de software y de las interfaces,
contiene la siguiente información:
 Clases, asociaciones y atributos.
 Interfaces, con sus operaciones y constantes.
 Métodos.
 Información sobre los tipos de los atributos
 Navegabilidad.
 Dependencias.
 El diagrama de diseño de clases también conocido con el
nombre de diagrama de clases, contiene entidades del
software en lugar de conceptos del mundo real.

 El propósito de este diagrama es el de representar los objetos
fundamentales del sistema, es decir los que percibe el usuario
y con los que espera tratar para completar su tarea en vez de
objetos del sistema o de un modelo de programación.
 Cada clase se representa en un rectángulo con tres
compartimentos:

Atributos
 Visibilidad: El encapsulamiento presenta 3 ventajas:
1. Se protegen los datos de accesos indebidos
2. El acoplamiento entre las clases se disminuye.
3. Favorece la modularidad y el mantenimiento.
Los atributos de una clase no deberían ser manipulables
directamente por el resto de objetos.
 Niveles de encapsulamiento:

Atributos

D) DIAGRAMA DE CLASES- Ejemploclass Diagrama de clases del diseño
EA 8.0 versión de prueba no registrada EA 8.0 versión de prueba no registrada EA 8.
cliente
- id_cliente: int
- nombre: char
+ altas() : void
+ bajas() : void
+ ConsultarCotizaciones() : void
+ modificacion() : void
Cotizacion
- detalle: char
- fecha_cotizacion: date
- id_cotizacion: int
+ AolicaDescuentos() : void
+ EnviaCotizacion() : void
+ Imprimir() : void
producto
- cantidad: int
- descripcion: char
- existencias: int
- id_producto: int
- precio_compra: long
- precio_venta: long
+ CalculoStockMinimo() : void
+ ConsultaEsxistencia() : void
+ consultar() : void
+ ConsultaxCategoria() : void
Ventas
- codigo: int
- detalle: char
- fecha: date
- hora: time
- subtotal: float
+ adicionar() : void
+ CancelarVentanaActual() : void
+ ImprimirVentaProducto() : void
Vendedor
- id_vendedor: int
- nombre: char
+ altas() : void
+ bajas() : void
+ Consultas() : void
+ modificaciones() : void
+elabora
0..*
+es elaborado por 1
+realiza
0..*
+es realizada
1..*
+presentan la oferta de
1..*
+es ofertado 1
+disponibles 1..*
+corresponde 1..*
+realizada
1..*
+solicitud
1..*

¿Cómo elaborar un DIAGRAMA
DE CLASES?
1. Identificar las clases que participan en la solución del
software, analizando los diagramas de interacción.
2. Dibujar las clases en un diagrama.
3. Duplicar los atributos provenientes de los conceptos del
modelo conceptual.
4. Agregar los nombres de los métodos analizando los
diagramas de interacción.
5. Incorporar la información sobre los tipos a los atributos y a
los métodos.
6. Agregar las asociaciones necesarias para dar soporte a la
visibilidad requerida de los atributos.
7. Agregar flechas de navegabilidad a las asociaciones para
indicar la dirección de la visibilidad de los atributos.
8. Agregar las líneas de relación de dependencia para indicar la
visibilidad no relacionada con los atributos.

D) DIAGRAMA DE CLASES- Ejemplo

D) DIAGRAMA DE CLASES EN

Desarrollo de un sistema con rup uml

Desarrollo de un sistema con rup uml

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Desarrollo de un sistema con rup uml

Similar a Desarrollo de un sistema con rup uml (20)

Último

Último (18)

Desarrollo de un sistema con rup uml