16-09-2024
Ingeniería de Software
Unidad 2
Etapas de la Ingeniería de Software
Docente: Alberto Marambio Riveros.
alberto.marambio02@[Link]
ISW – Unidad 2
1
16-09-2024
ISW – Unidad 2
Criterios de Evaluación 2 (ponderación 25%).
ISW – Unidad 2
Bibliografía.
Especificación de sistemas software en UML
Ciclo de vida de desarrollo ágil de software seguro.
Disponibles en biblioteca virtual – eLibro.
4
2
16-09-2024
U M L
Unified Modeling Language
UML
→ Lenguaje de propósito general para el modelamiento de
sistema bajo un enfoque orientado a objetos
→ Impulsado por el Object Management Group ([Link])
→ Versión actual = UML 2.5.1 - 2017 ([Link])
→ UML no es una metodología, sólo provee mecanismos para
representar diversos aspectos de un sistema real
→ Propone un conjunto de diagramas que permiten modelar un
sistema desde distintos puntos de vista
→ Los diagramas UML se pueden clasificar en tres vistas
principales:
→ Vista Funcional
→ Vista Estática
→ Vista Dinámica
→ Algunos diagramas UML se pueden clasificar dentro de una 4ª
vista denominada vista de implementación
6
3
16-09-2024
Diagramas UML
Vista Estática
Diagrama de clases
Diagrama de objetos
Vista Dinámica
Vista Funcional
Diagrama de secuencia
Diagrama de casos de uso DIagrama de colaboración
Diagrama de actividad Diagrama de estados
Vista de Implementación
Diagrama de paquetes
Diagrama de componentes
Diagrama de distribución
7
UML – Vista Funcional
CASOS DE USO
4
16-09-2024
UML – Diagrama de Casos de Uso
Especificación de Requerimientos:
→En un proyecto de desarrollo de software, uno de los primeros
pasos es la especificación de requerimientos
→En otras palabras significa definir la funcionalidad que debe
proporcionar el sistema
→UML provee el diagrama de casos de uso para modelar la
vista funcional del sistema
→En general este diagrama puede representar:
→ Las funcionalidades del sistema
→ Las interacciones de los usuarios con el sistema
→ Las interacciones existentes entre las funciones del sistema
→ El entorno en dónde se desenvuelve el sistema (opcional)
→El diagrama de casos de uso se complementa con elementos
narrativos y en algunos casos, con diagramas de actividad
9
UML – Diagrama de Casos de Uso
Tipos de Requerimientos:
→Funcionales: Relacionados con la actividad comercial y
administrativa del negocio. Los sistemas informáticos deben
apoyar estas actividades. Son fácilmente conocidos por los
usuarios
→No Funcionales: No están relacionados directamente con la
actividad del negocio. Generalmente no son conocidos por
los usuarios, pero los técnicos los deben conocer y especificar.
Ejemplos:
→ Restricciones: Limitaciones que afectan el desarrollo del sistema
(experiencia de los usuarios, leyes, normativas, contratos,
estándares de la industria, plataforma tecnológica, bases de
datos existentes, etc.)
→ Rendimiento: Relacionado con la calidad de funcionamiento
del sistema (velocidad de proceso, tiempo de respuesta,
eficiencia del código, etc.)
10
10
5
16-09-2024
UML – Diagrama de Casos de Uso
Propósitos del Modelamiento de Casos de Uso:
La principal diferencia entre los casos de uso y el diseño
funcional es el enfoque.
El diseño funcional documenta el proceso, el caso de uso se
enfoca en el objetivo del proceso.
Enfocarse en el proceso, generalmente conduce a reproducir
sistemas existentes, porque se enfoca en el cómo en vez del
porqué.
Utiliza tres puntos de vista distintos para describir cada
requerimiento del sistema:
Diagrama de casos de uso.
Descripción de los casos de uso
Escenarios de los casos de uso
11
11
UML – Diagrama de Casos de Uso
Casos de Uso - Resumen:
Los casos de uso son una técnica para capturar y
documentar los requerimientos funcionales de un
sistema (qué es lo que debe hacer el sistema)
Permiten describir las interacciones típicas entre los
usuarios de un sistema y el sistema mismo,
proporcionando una narración acerca de cómo se
usa el sistema
Un escenario (dentro de un CDU) es una secuencia
de pasos que describen una interacción particular
entre un usuario y un sistema
12
12
6
16-09-2024
UML – Diagrama de Casos de Uso
Ejemplo de Escenario de Caso de Uso:
Compra en línea por Internet:
El cliente abre el navegador Internet, navega por el catálogo en
línea y agrega los ítems deseados al carrito de compra.
Cuando el cliente desea pagar, indica la compra y la información
de su tarjeta de crédito y luego confirma la compra.
El sistema chequea la autorización de la tarjeta de crédito y en
caso positivo, inmediatamente confirma la venta mostrando un
mensaje en pantalla y enviando un e-mail al usuario.
→ Puede haber otros escenarios (falla en la verificación de la tarjeta,
otra forma de pago, etc.)
→ Todos los escenarios son diferentes, pero tienen el mismo objetivo:
Comprar un producto por Internet
→ Un caso de uso es un conjunto de escenarios relacionados con un
objetivo común.
13
13
UML – Diagrama de Casos de Uso
Componentes Diagrama Casos de Uso:
→Casos de Uso: Representan las funcionalidades que debe
entregar el sistema bajo estudio (requerimientos que debe
cumplir)
→Actores: Representan a los usuarios, sistemas y/o dispositivos
que interactúan con el sistema bajo estudio
→Asociaciones: Representan las interacciones entre actores y
casos de uso
→Dependencias: Representa una interacción entre casos de
uso, en que un caso de uso invoca alguna funcionalidad en
otro caso de uso
→Generalización: Representa las relaciones jerárquicas de
herencia entre casos de uso
14
14
7
16-09-2024
UML – Diagrama de Casos de Uso
Ejemplo Diagrama Casos de Uso: sistema
Actor
dependencia
Caso de uso asociación
15
15
UML – Diagrama de Casos de Uso
Ejemplo Diagrama Casos de Uso:
caso de uso
herencia
actor
dependencia
16
16
8
16-09-2024
UML – Diagrama de Casos de Uso
Ejemplo Diagrama Casos de Uso:
dependencia
herencia
caso de uso
actor
17
17
UML – Diagrama de Casos de Uso
Manejo de la Herencia:
18
18
9
16-09-2024
UML – Diagrama de Casos de Uso
Descripción de Casos de Uso:
Asunciones: Condiciones que se deben cumplir antes que se ejecute el
caso de uso. Reflejan el estado del sistema al momento de invocar el
caso de uso. Las asunciones NO son verificadas por el caso de uso
(por ej: autenticación de usuarios)
Pre-condiciones: Deben ser verificadas inicialmente por el caso de uso.
Si no se cumplen, se niega el acceso al actor (por ej: validación de
parámetros de entrada)
Iniciación del CDU: Especifica quién o qué da inicio al caso de uso,
puede ser un usuario, un dispositivo, otro sistema, etc.
Proceso o diálogo: Descripción paso a paso de la interacción entre el
caso de uso y el actor seudolenguaje o diagrama de actividades
Terminación del CDU: Opciones y condiciones de término del caso de
uso
Post-condiciones: Describe el estado en que debe quedar el sistema
una vez que finaliza el caso de uso
19
19
UML – Diagrama de Casos de Uso
Actividad Grupal:
Una clínica médica desea modelar el sistema de atención de
pacientes, para lo cual explica lo siguiente: El sistema debería
apoyar a las secretarias para que los pacientes puedan
reservar y/o cancelar horas de atención con los médicos. A su
vez el sistema debe apoyar a los médicos para que puedan
registrar los datos de las consultas de los pacientes. Una vez
que la consulta se ha efectuado los pacientes deben acudir a
la caja para pagar la cuenta de la consulta, en este caso el
sistema también debe apoyar a los cajeros para identificar los
tipos y valores de las consultas
→Se pide modelar un diagrama de casos de uso, identificando
actores, casos de uso (funcionalidades) y asociaciones
→Considerar:
→ Actores sustantivos
→ Casos de uso verbos
→ Asociaciones quién hace qué 20
20
10
16-09-2024
UML – Diagrama de Casos de Uso
Descripción del Problema – Control de Inventario
Recepción → El personal de recepción recibe los cargamentos que llegan, comparando
las órdenes de compra contra el stock del cargamento. Luego informan al depto. Cuentas
por pagar cuando los productos de la orden de compra han sido recibidos. Los usuarios
desean que el nuevo sistema maneje estas notificaciones automáticamente.
Inventario → Los productos pueden ingresar debido a órdenes canceladas, órdenes
devueltas, o cargamento de los proveedores. Los productos son almacenados en la
bodega, en ubicaciones predefinidas. El encargado del inventario busca las ubicaciones
correctas para los productos recibidos, almacena los productos en esa ubicación y
actualiza el inventario de esa ubicación con la cantidad de productos recibidos.
Atención órdenes de clientes → Otros miembros del personal atienden las órdenes de
clientes, ubicando los productos requeridos para cada orden. A medida que completan
las órdenes, van actualizando el inventario para registrar los productos que se sacaron
para atender la orden. También notifican al depto. de procesamiento de órdenes, cuando
las órdenes están completas. Los usuarios desean que el sistema maneje las
notificaciones al depto. De procesamiento de órdenes.
Despacho → Cuando las órdenes de clientes están completas, los productos son
empaquetados y preparados para el transporte. El personal de empaque contacta a los
transportistas para coordinar la entrega de los productos. Luego actualizan el inventario
después que se han embarcado los productos. Los usuarios desean que el nuevo sistema
maneje las notificaciones al depto. de procesamiento de órdenes.
22
22
UML – Diagrama de Casos de Uso
Nombre Atender Orden Cliente
Asunciones Sólo los usuarios validos tienen acceso a esta característica (función).
Pre-condiciones Proveer (ingresar) un número de orden válido.
Iniciación del CDU Se inicia según demanda del usuario
Diálogo El sistema pide al usuario un número de orden
El usuario provee el número de orden
El sistema verifica la orden (mediante CDU Buscar Orden)
Si la orden no se encuentra: mensaje de error y finalizar
Sino
El sistema provee los datos de la orden al usuario
El usuario selecciona un ítem de la orden
Hasta que el usuario indica que está listo o no hay más ítems pendientes con cantidad requerida mayor que
cero:
El sistema pide la ubicación del ítem (mediante CDU Ubicar Producto)
Si el ítem es encontrado (disponible)
El usuario indica la cantidad requerida
Si hay ítems pendientes con cantidad requerida mayor que cero
Generar una orden de entrega diferida (mediante CDU Crear Orden
Diferida)
Terminación del CDU El usuario puede cancelar
El CDU puede expirar (timeout)
El usuario puede indicar que terminó
El usuario puede llenar todos los ítems de la orden
Post-condiciones Terminación normal:
Los cambios de la orden deben ser salvados
(la orden diferida es manejada por el CDU Crear Orden Diferida)
Cancelación:
La orden debe ser salvada sin cambios.
Si se generó una orden diferida, se debe cancelar
24
24
11
16-09-2024
ISW – Unidad 2
Herramientas.
⚫ Visual Paradigm → Herramienta de diseño de software, orientada a proyectos de
software con metodologías ágiles. Su versión comercial soporta UML, BPMN, SysML,
prototipos, entre otros.
⚫ Cuenta con una versión Community, la cual restringe algunas funcionalidades, pero es
útil para trabajar con UML. Se puede descargar desde →
[Link]
Seleccionar versiones para Windows, Mac
25
25
UML – Vista Funcional
DIAGRAMAS DE ACTIVIDAD
26
26
12
16-09-2024
UML – Vista Funcional
Diagrama de Actividad - Objetivos:
→ Reconocer y entender las situaciones en que se
puede utilizar un diagrama de actividad
→ Reconocer los componentes de un diagrama de
actividad
→ Entender un diagrama de actividad modelado por
otra persona
→ Practicar el modelamiento de actividades
mediante ejemplos simples
27
27
UML – Vista Funcional
Diagrama de Actividad:
→Permite modelar las funciones o procesos lógicos que
posteriormente se implementarán mediante código
→Cada proceso o función describe una secuencia de tareas e
instancias de decisión que las gobiernan
→UML propone el uso de diagramas de actividad en 3
situaciones:
→ Descripción de operaciones de clases (operaciones / métodos)
→ Descripción de casos de uso
→ Descripción de procesos de negocio (workflow)
→Una Actividad se entiende como un conjunto de acciones o
tareas dispuestas en alguna secuencia determinada
→UML define un conjunto de elementos gráficos que permiten
representar una actividad dentro de un sistema
28
28
13
16-09-2024
UML – Diagrama de Actividad
Inicio de Actividad
Fin de Actividad
Acción o Tarea
Punto de Decisión / Unión de flujos
Transición
Punto de Concurrencia (Fork)
Punto de Sincronización (Join)
29
29
UML – Diagrama de Actividad
Ejemplos:
→Una acción o tarea es un paso dentro de un proceso, la cual
ejecuta algún trabajo (cálculos, verificación, comparación,
etc.)
→Una transición ocurre cuando se completa una acción
→Un diagrama de actividad es una secuencia de acciones y
puntos de decisión, unidas mediante transiciones
30
30
14
16-09-2024
UML – Diagrama de Actividad
Condición Guard:
→ A veces una transición sólo puede ocurrir si se cumple cierta
condición
→ Una condición restringe el uso de la transición
→ La condición se indica dentro de paréntesis de corchete, cerca de
la flecha de transición
→ La condición debe ser verdadera para que ocurra la transición y se
continúe con la siguiente acción.
31
31
UML – Diagrama de Actividad
Puntos de Decisión:
→ Representan pasos alternativos mutuamente excluyentes, luego en
cada punto de decisión, sólo se puede seleccionar un único paso
→ Cada paso se evalúa mediante una condición guard
→ Toda la información necesaria para tomar la decisión debe estar
disponible dentro de la actividad
La información requerida
La información requerida para la
para la decisión está
decisión se acumuló en los pasos
contenida en la acción
previos
32
32
15
16-09-2024
UML – Diagrama de Actividad
Concurrencia:
→Permite modelar características de fork
lenguajes que manejan concurrencia
a nivel de hardware (Java, C++,
Smalltalk, Pascal concurrente, etc.)
→Si un proceso es capaz de iniciar
múltiples hebras o subprocesos
concurrentes, se utiliza la construcción
fork
→La sincronización o mezcla de
procesos concurrentes se modela
mediante la construcción join
→La concurrencia también se puede
representar en el modelamiento de
procesos de negocio unión de join
flujos
33
33
UML – Diagrama de Actividad
Descomposición de una Acción:
→ Un conjunto de acciones se puede modelar como una sub-actividad
→ Una sub-actividad se modela con una construcción similar a una
acción, es decir, un rectángulo con esquinas redondeadas
→ Pero una sub-actividad debe tener un nombre propio
→ Además, puede tener parámetros de entrada y salida (objetos)
34
34
16
16-09-2024
UML – Diagrama de Actividad
Ejemplo de Descomposición de Acción:
Parámetro
de salida
Invocación
de método
Parámetro
de entrada
35
35
UML – Diagrama de Actividad
Ejemplo Subactividad con Parámetro de Entrada:
36
36
17
16-09-2024
UML – Diagrama de Actividad
Actividad Grupal:
Proceso de matrícula e inscripción de
asignaturas
→Modelar un diagrama de actividad
indicando todas las tareas secuenciales o
paralelas y los puntos de decisión o unión de
flujos
37
37
UML – Diagrama de Actividad
Particiones:
→En un diagrama de actividad simple no se indica quién realiza
qué acción, es decir, no se indica el responsable de la acción
→Al modelar casos de uso o métodos de clase, importa definir
qué es lo que se debe hacer
→En el modelamiento de procesos de negocio puede ser
importante definir quién tiene las responsabilidades por las
diferentes acciones
→En estos casos se pueden usar particiones que indiquen
divisiones de responsabilidad dentro de un diagrama de
actividad
→Técnicamente las particiones se denominan swimlanes y
pueden indicar distintos tipos de divisiones dentro de un
diagrama de actividad
38
38
18
16-09-2024
UML – Diagrama de Actividad
Tipos de Particiones (Swimlanes):
39
39
UML – Diagrama de Actividad
Ejemplo:
40
40
19
16-09-2024
UML – Diagrama de Actividad
Actividad Grupal:
Para retirar dinero desde su cuenta, un cliente inserta su tarjeta en el
cajero automático, luego ingresa su pin, el cual es verificado en los
registros del banco. Si el pin es inválido se expulsa la tarjeta y el
cliente la debe retirar; si el pin es válido, el cliente debe ingresar el
monto a retirar, el cual nuevamente es verificado en el banco,
contra el saldo de la cuenta del cliente. Si el saldo es menor que el
monto a retirar, se imprime un comprobante con el saldo y se expulsa
la tarjeta; si el monto a retirar es menor o igual al saldo de la cuenta,
el cajero entrega el dinero y paralelamente el banco contabiliza el
giro en la cuenta del cliente. Una vez que el cliente retira el dinero de
la bandeja se imprime un comprobante y se expulsa la tarjeta, la
cual debe ser retirada por el cliente
→ Modelar un diagrama de actividad indicando todas las acciones
contenidas en la descripción, ordenándolas en particiones
41
41
CDU – Identificación de Escenarios
Identificar los distintos escenarios posibles, según las condiciones que los
definen
43
43
20
16-09-2024
UML – Vista Dinámica
Escenario N° 1
ant
ant
44
44
UML – Vista Dinámica
Escenario N° 2
ant
ant 45
45
21
16-09-2024
UML – Vista Dinámica
Escenario N° 3
1
2
46
46
UML – Vista Dinámica
Escenario N° 4
1
2
Para cada escenario se debe definir un diagrama de secuencia
47
47
22
16-09-2024
UML – Diagrama de Actividad
Actividad Grupal:
El departamento de desarrollo de software tiene un área de soporte
que atiende problemas vía telefónica o vía e-mail. Al recibir una
solicitud de soporte, esta área crea un ticket de atención con un Nº
único y lo deriva al área de SQA, la cual debe revisar el software y
reproducir el problema reportado. Si no puede reproducir el
problema debe actualizar la información del ticket entrevistando al
usuario. Una vez que se reproduce el error, se informa al área de
mantención para que identifique el error. Si no se puede identificar el
error, debe actualizar la información del ticket entrevistando al
usuario. Una vez identificado el error, el área de mantención diseña
una solución y aplica las modificaciones necesarias en el software.
Luego se informa al área SQA, la cual verifica que la solución
aplicada funciona correctamente, si es así, se cierra el ticket de
atención; de otra manera se informa al área de mantención para
que identifique nuevamente el error y siga el flujo de atención del
ticket
→ Modelar un diagrama de actividad indicando todas las tareas
contenidas en la descripción, luego identificar los escenarios posibles.
48
48
UML – Diagrama de Actividad
Extensiones al Diagrama de Actividad (útil para workflow):
Evento (aceptar)
Evento (enviar)
Evento de tiempo
Pines
Región de expansión
50
50
23
16-09-2024
UML – Diagrama de Actividad
Señales o Eventos:
→ Una acción puede ser iniciada a partir de una señal o evento
→ Una señal indica que la acción recibe un evento externo al proceso.
En este caso la acción debe estar atenta a la aparición de la señal
→ Una acción también puede generar señales hacia el exterior
→ Una señal de tiempo es un evento que ocurre en un instante
determinado, o después de transcurrido un tiempo determinado
Ejemplo:
51
51
UML – Diagrama de Actividad
Ejemplo Eventos:
52
52
24
16-09-2024
UML – Diagrama de Actividad
Tokens y Objetos:
→ Los diagramas de actividad contienen múltiples flujos (transiciones) que
conectan a una secuencia de acciones.
→ Tales flujos se pueden considerar como una red de cañerías por donde viaja
un fluido, o un conjunto de cables por donde se transmite la electricidad .
→ Esta red de flujos por sí sola no es capaz de iniciar las acciones conectadas a
ella. Luego se requiere que “algo” invisible transite por esta red y que tenga la
capacidad de iniciar una acción (por ejemplo, cuando se enciende un
interruptor la electricidad fluye por el cable y enciende una ampolleta). A
este “algo” que fluye bajo ciertas circunstancias se le denomina Token.
→ En un proceso de negocio, un token puede ser un documento, un mensaje,
una señal, un elemento físico, que origina la partida de una acción.
Flujo de
Flujo de Flujo de Objeto objeto
control objeto
53
53
UML – Diagrama de Actividad
Pines:
→ Una acción puede requerir parámetros para hacer su trabajo
→ Generalmente no se requiere mostrar esta información en el
diagrama, pero en caso que se requiera, se puede indicar mediante
pines
→ Un pin se representa por un pequeño cuadrado en el borde de una
acción
→ Una acción puede tener pines de entrada y pines de salida
→ Los pines de entrada son un pre-requisito para que una acción
pueda iniciarse. Luego una acción no se podrá ejecutar mientras no
tenga tokens en todos sus pines de entrada
→ No es obligatorio el uso de pines en un diagrama de actividad
→ La utilización de pines tiene utilidad cuando se requiere detallar los
datos necesarios y producidos por varias acciones
→ En modelamiento de procesos de negocio, los pines pueden
representar los recursos consumidos y/o generados por las distintas
acciones 54
54
25
16-09-2024
UML – Diagrama de Actividad
Ejemplo Uso de Pines: Pin salida/entrada
Estado del
objeto
Flujos de objeto 55
55
UML – Diagrama de Actividad
Regiones de Expansión:
→ En algunos casos puede requerirse que una acción sea ejecutada repetidas veces,
pero con distintos valores, los cuales se entregan agrupados.
→ Esta situación se puede representar mediante una región de expansión.
Conjunto valores entrada
Tipo de región de exp:
parallel, iterative, stream
Conjunto valores salida
→ Dentro del área segmentada puede haber una sola acción o varias acciones.
→ El conjunto de acciones dentro del área segmentada se ejecuta una vez por cada
elemento en el conjunto de valores de entrada.
→ Cada ronda de ejecución producirá un elemento en el conjunto de valores de
salida
→ La ejecución no se puede iniciar hasta que estén disponibles todos los valores de
entrada.
→ Los valores de salida no estarán disponibles hasta que terminen todas las 56
ejecuciones.
56
26
16-09-2024
UML – Diagrama de Actividad
Regiones de Expansión (cont.):
→ Los ítems dentro de una misma colección de valores deben ser del mismo
tipo.
→ No necesariamente deben coincidir las cantidades de valores de entrada y
salida (una región de expansión puede actuar como un filtro).
→ Tipos:
→ Parallel: Las acciones internas son independientes entre sí
→ Iterative: Una ejecución de las acciones a la vez
→ Stream: Existe un flujo continuo de valores en una única ejecución
57
57
UML – Diagrama de Actividad
Actividad Grupal:
Una oficina de contratación recibe un conjunto de solicitudes
de trabajo que debe verificar. Por cada solicitud se debe
verificar que contenga todos los documentos exigidos.
Paralelamente se deben revisar los antecedentes comerciales
de las personas que enviaron las solicitudes de trabajo, en
base a información de DICOM. En caso que todo esté
correcto, las solicitudes se guardan para enviarlas a las
empresas que ofrecen puestos de trabajo. En caso contrario
las solicitudes se devuelven.
Se pide Modelar un diagrama de actividad que muestre una
región de expansión conteniendo las acciones descritas
anteriormente
58
58
27
