Parte 2

Introducción al proceso de desarrollo
Fase de construcción: ciclos de desarrollo
z La fase de construcción de un proyecto requiere varios

ciclos de desarrollo a lo largo de los cuales se extiende el
sistema.
y El objetivo final es obtener un sistema funcional que atienda
debidamente los requerimientos.
z En un ciclo individual de desarrollo, los principales pasos se

analizan y diseñan, como se señala en la figura siguiente.
UTFSM
EXUMBRA
IN
SOLEM Fundamentos de Ingeniería de SW 1

Ciclo de Ciclo de Ciclo de

desarrollo 1 desarrollo 2 desarrollo 3
Perfeccionami Sincronización Análisis Diseño Construcción Prueba

ento del plan de artefactos
1. Definir casos 2. Perfeccionar 3. Perfeccionar 4. Perfeccionar

esenciales de el diagrama de el modelo el glosario
uso casos conceptual
5. Definir 6. Definir los 7. Definir

diagramas de contratos de diagramas de
secuencia operaciones estado
UTFSM
EXUMBRA
IN
1
z Como en el caso de los artefactos de la fase de

requerimientos, algunos artefactos pueden ser creados en
paralelo, por ejemplo:
y Modelo conceptual y glosario.

y Diagramas de interacción y diagramas de diseño de clases.
UTFSM
EXUMBRA
IN

Cuando crear el modelo conceptual
z El modelo conceptual es una representación de conceptos

u objetos en el dominio del problema, como Libro y
Biblioteca.
z Debe limitarse el esfuerzo aplicado a la creación de un

modelo conceptual preliminar en la fase de planificación y
elaboración, ya que en los dominios de problemas amplios,
el modelo conceptual puede tornarse muy complejo.
UTFSM
EXUMBRA
IN
2
Cuando crear el modelo conceptual
z La estrategia recomendada es generar rápidamente un

modelo conceptual que se centre en identificar los
conceptos obvios expresados en los requerimientos y
posponer hasta más tarde una investigación con
detenimiento.
z Otra estrategia es suspender la creación de un modelo

conceptual hasta el inicio de los ciclos de desarrollo, lo cual
tiene la desventaja de aplazar la complejidad.
UTFSM
EXUMBRA
IN

Cuando crear los casos expandidos de uso
z Durante la fase de planificación y elaboración, se aconseja

crear todos los casos de uso de alto nivel, pero describir
los más importantes en el formato expandido, posponiendo
el resto hasta el ciclo de desarrollo en que se estudian.
z Por lo tanto se recomienda estudiar detenidamente,

durante la fase de planificación y elaboración sólo los
casos de uso más importantes.
UTFSM
EXUMBRA
IN
3
Definición de modelos y artefactos
z UML describe modelos de sistema basado en los conceptos

de objetos.
z Todos los diagramas de UML pueden ser divididos en dos

tipos.
y Un modelo estático del sistema describe las propiedades
estructurales del sistema.
y Un modelo dinámico describe las propiedades del comportamiento
del sistema.
UTFSM
EXUMBRA
IN

Modelo del sistema
z El modelo global del sistema esta constituido por:
z Modelo de análisis: el que se relaciona con una

investigación de dominio y del ámbito del problema, pero
no con la solución.
z Modelo de diseño: el que se relaciona con la solución

lógica.
UTFSM
EXUMBRA
IN
4
Relación entre los artefactos
z Sin importar como los artefactos se organicen para

construir los modelos, se dan dependencias muy
importantes entre ellos.
y Por ejemplo, un diagrama de casos de uso depende de las
definiciones de los casos de uso.
z Si se crea un artefacto que no tenga otros dependientes y

si no se usa como entrada de otra cosa, habrá que poner
en tela de juicio su valor y el tiempo que se dedicó a su
creación.
UTFSM
EXUMBRA
IN

Relación entre los artefactos
Informe
preliminar de Especificación de
investigación requerimientos
Casos de uso:
a)de alto nivel todos
b) algunos esenciales
Prototipos expandidos
Diagramas de casos de
uso
Presupuesto,
programa de Modelo conceptual
actividades preliminar
Glosario
UTFSM
EXUMBRA
IN
5
Análisis y diseño orientado a objetos
Resumen
z ¿Qué es análisis?
z ¿Qué es diseño?
z Análisis y diseño OO
z Uso de UML
z Introducción al proceso de desarrollo
UTFSM
EXUMBRA
IN
Análisis y diseño orientado a objetos

Quiz
z ¿Cuál es la diferencia entre análisis y diseño OO?

z ¿Porqué UML tiene tantos diagramas?
z ¿De qué sirve el “divide y vencerás” en OO?
z ¿Qué es un proceso de desarrollo?
z ¿Qué pasa dentro de un ciclo de desarrollo?
UTFSM
EXUMBRA
IN
6
Fase de planificación y elaboración
Contenido
z Especificación de Requerimientos
z Casos de Uso: Descripción de Proceso
z Clasificación de los casos de uso
z Inicio de un ciclo de desarrollo
UTFSM
EXUMBRA
IN

Especificación de requerimientos
z Con esta actividad se quieren lograr los siguientes

objetivos:
y Crear los artefactos de la fase de requerimientos, por ejemplo, las
especificaciones de funciones.
y Identificar y clasificar las funciones del sistema.
y Identificar y crear los atributos del sistema y relacionarlos con las
funciones.
UTFSM
EXUMBRA
IN
7
Captura de Requerimientos
z Requerimientos son una descripción de necesidades o

deseos para un producto.
x El reto consiste en definirlos de manera inequívoca, de modo que se
detecten los riesgos y no se presenten sorpresas al momento de
entregar el producto.
z Los siguientes tópicos son recomendados a ser
desarrollados en esta fase:
• declaración general
• clientes
• objetivos
• funciones del sistema
• atributos del sistema
UTFSM
EXUMBRA
IN

Ejemplo: Punto de venta
z Declaración general: el propósito de este proyecto es crear un sistema

de punto de venta para ser usada en locales de venta.
z Clientes: Placeres Terrenales, Ltda, vendedor multinacional de objetos
de relajación
z Objetivos: En general, la meta es hacer más rápido el procedimiento
de pago de productos, para apoyar en forma mejor, más rápida y
barata los procesos de servicios y negocios. Más específicamente esto
incluye
y Rápido pago y entrega de comprobante a los compradores
y Rápido y preciso análisis de ventas
y Control del inventario automático
UTFSM
EXUMBRA
IN
8
Funciones y atributos del sistema
z Funciones del sistema son aquellas que el sistema se

supone que tiene que hacer, tales como autorizar el pago
con las tarjetas de crédito.
y Estas deben ser identificadas y anotadas en grupos lógicos y
cohesivos.
z Con el objeto de verificar que algún X es de verdad una
función del sistema, la siguiente oración deberá tener
sentido:
y El sistema deberá hacer <X>.
y Por ejemplo: El sistema deberá autorizar los pagos con tarjetas de
crédito.
UTFSM
EXUMBRA
IN

z En cambio, los atributos del sistema son cualidades no-

funcionales del sistema, como por ejemplo, la facilidad de
uso, que a menudo se confunden con las funciones del
sistema.
y Nótese que facilidad de uso no encaja en la oración de verificación:

El sistema deberá hacer la facilidad de uso.
y Los atributos no deben formar parte de las especificaciones
funcionales del sistema, sino de un documento independiente que
especifica sus atributos.
UTFSM
EXUMBRA
IN
9
z Las funciones deben ser clasificadas en categorías para

poder priorizarlas.
z Las categorías incluyen:

y Funciones Evidentes - Debe realizarse, el usuario esta consciente
que se ha realizado.
y Funciones Ocultas - Debe realizar, pero no debe ser visible a los
usuarios.
y Funciones Superfluas - Opcionales; su agregación no afecta
significativamente en el costo o en otras funciones.
UTFSM
EXUMBRA
IN

z Las siguientes funciones básicas del sistemas en la

aplicación del punto de venta son una muestra
significativa; no pretenden en absoluto ser exhaustivas.
Ref # Función Categoría

R1.1 Registrar la venta en proceso (actual): la lista de los artículos Evidente
comprados
R1.2 Calcular el total de la venta actual, incluyendo impuestos y descuentos Evidente
…
R1.5 Registrar las ventas completadas Oculta
…
R1.9 Mostrar la descripción y el precio del item Evidente
UTFSM
EXUMBRA
IN
10
z Sería mejor agrupar funciones en un orden lógico, por

ejemplo, todas las funciones de pago.
Ref # Función Categoría

R2.1 Manejar los pagos con efectivo, capturando la cantidad entregada y Evidente
entregando el monto de vuelto
R2.2 Manejar los pagos con las tarjetas de crédito, capturando la Evidente
información de la tarjeta tanto por el lector como manualmente
…
R2.4 Registrar los pagos con la tarjeta de crédito en el sistema de Oculta
contabilidad, para cobrarlos después a los bancos.
UTFSM
EXUMBRA
IN

z Los atributos del sistema son características o dimensiones

del mismo: no son funciones.
y Por ejemplo, facilidad de uso, tolerancia a fallas, plataformas,
tiempo de respuesta, etc.
z Los atributos tienen un posible conjunto de detalles de

atributos, los cuales tienden a ser valores discretos,
confusos o simbólicos, por ejemplo:
x Tiempo de respuesta = (psicológicamente correcto)
x Facilidad de Uso =(¿???)
UTFSM
EXUMBRA
IN
11
z Algunos atributos del sistema también pueden tener

restricciones de frontera del atributo, que son condiciones
obligatorias, generalmente dentro de un rango numérico
de los valores de un atributo, por ejemplo:
x Tiempo de respuesta = (5 segundos cómo máximo)
Atributo Detalle y limitación

Tiempo de respuesta (restricción de frontera) La descripción y el
precio aparecerán en menos de 5 segundos.
Sistema Operativo (detalle) Microsoft Windows 95 y NT
UTFSM
EXUMBRA
IN

z Atributos del sistema en especificaciones de las funciones

relacionan los atributos con las funciones que son
afectados por ellos, además de definir el atributo
obligatorio u opcional.
y Una restricción de frontera suele ser obligatoria, pues de lo
contrario significaría que no era sólida.
Ref# Función Categ. Atributo Detalles y Categ.

Limitaciones
R1.9 Mostrar la Evidente Tiempo de respuesta La descripción y el Requerido
descripción y el precio aparecerán en
precio del item menos de 5 segundos.
UTFSM
EXUMBRA
IN
12
Casos de uso: Descripción de procesos
z Objetivos:
y Identificar y escribir casos de uso

y Diseñar diagramas de casos de uso.
y Contrastar los casos de uso de alto nivel, tanto como expandidos.
y Contrastar los casos de uso esenciales con los reales.
UTFSM
EXUMBRA
IN

z La técnica de casos de uso se puede aplicar tanto al

análisis estructurado, como al análisis orientado a objetos.
z Un caso de uso es un documento narrativo que describe la

secuencia de eventos de un actor (agente externo) que
utiliza un sistema para completar un proceso.
y Los casos de uso son historias o casos de utilización de un sistema.
y No son exactamente los requerimientos ni las especificaciones
funcionales, sino que ejemplifican e incluyen tácitamente los
requerimientos en las historias que narran.
UTFSM
EXUMBRA
IN
13
z Notación en UML
Comprar productos
z El siguiente caso de uso de alto nivel describe clara y
concisamente el proceso de comprar artículos en una
tienda cuando se emplea una terminal en el punto de
venta.
Caso de uso: Comprar productos
Actores: Cliente, Cajero
Tipo: Primario
Descripción: Un cliente llega a la caja registradora con los artículos que comprará.
El Cajero registra los artículos y cobra el importe. Al terminar la
operación, el Cliente se marcha con los artículos comprados.
UTFSM
EXUMBRA
IN

z Un caso de uso expandido muestra más detalles que uno

de alto nivel
y este tipo de casos suelen ser útiles para alcanzar el conocimiento
más profundo de los procesos y de los requerimientos.
Caso de uso: Comprar productos en efectivo

Actores: Cliente (iniciador), Cajero
Propósito: Capturar una venta y su pago en efectivo.
Resumen: Un cliente llega a la caja registradora con los artículos que comprará.
El Cajero registra los artículos y recibe un pago en efectivo. Al
terminar la operación, el Cliente se marcha con los artículos
comprados.
Tipo: Primario
Referencias Funciones: R1.1, R1.2, R1.3, R1.7, R2.1
Cruzadas:
UTFSM
EXUMBRA
IN
14
Curso Normal de Eventos
Acción de los actores Respuesta del sistema

1. Este caso de uso comienza cuando un
Cliente llega a una caja de TPDV (Terminal
de Punto de Ventas) con productos que
desea comprar.
2. El Cajero registra la identificación de cada 3. Determina el precio del producto e
producto. incorpora a la transacción actual la
Si hay varios productos de una misma información correspondiente.
categoría, el Cajero también puede introducir Se presentan la descripción y el precio del
la cantidad. producto actual.
4. Al terminar de introducir el producto, el 5. Calcula y presenta el total de la venta.
Cajero indica a TPDV que se concluyo la
captura del producto.
6. El Cajero indica el total al Cliente.
UTFSM
EXUMBRA
IN

Curso Normal de Eventos
7. El Cliente efectúa el pago en efectivo – el

“efectivo ofrecido” – posiblemente mayor
que el total de la venta.
8. El Cajero registra la cantidad de efectivo 9. Muestra al cliente la diferencia. Genera un
recibida. recibo.
10. El Cajero deposita el efectivo recibido y 11. Registra la venta concluida.
extrae el cambio de pago.
El Cajero le da al Cliente el cambio y el
recibo impreso.
12. El Cliente se marcha con los artículos
comprados.
Cursos alternativos
• Línea 2: introducción del identificador inválido. Indicar error.
• Línea 7: el cliente no tenía suficiente dinero. Cancelar la transacción de venta.
UTFSM
EXUMBRA
IN
15
Explicación del formato expandido
Caso de uso: Nombre del caso de uso

Actores: Lista de actores (agentes externos), en la cual se indica quien inicia el
caso de uso.
Propósito: Intención de caso de uso
Resumen: Repetición del resumen de alto nivel o alguna síntesis similar.
Tipo: 1. Primario, secundario u opcional
2. Esencial o real
Referencias Casos relacionados de uso y funciones también relacionadas del
Cruzadas: sistema.
UTFSM
EXUMBRA
IN

z La sección intermedia, curso normal de eventos, es la

parte medular del formato expandido
y Se describe en detalles la conversación interactiva entre los actores
y el sistema.
y Un aspecto esencial de la sección es que explica la secuencia más
común de los eventos; no incluye situaciones alternativas.
Acción del actor Respuesta del sistema

Acciones numeradas de los actores Descripciones numeradas de las respuestas
del sistema.
UTFSM
EXUMBRA
IN
16
z La última sección, curso alternativo de los eventos ,

describe importantes opciones o excepciones que pueden
presentarse en relación con el curso normal.
y Si son complejas, se pueden expandir y convertirlas en otros casos
de uso.
Cursos alternativos
Alternativas que pueden ocurrir en el número de línea. Descripción de
excepciones.
UTFSM
EXUMBRA
IN

Actores
z El actor es una entidad externa del sistema que de alguna

manera participa en la historia del caso de uso.
y Por lo regular estimula el sistema con eventos de entrada o recibe
algo de él.
y Los actores están representados por papel que desempeñan en el
caso: Cliente, Cajero, u otro.
z Notación en UML
Cajero
UTFSM
EXUMBRA
IN
17
Actores
z En un caso de uso hay un actor iniciador que produce la

estimulación inicial y, posiblemente, otros actores
participantes; tal vez convenga especificar quien es el
iniciador.
y Los actores suelen ser los papeles representados por las personas,
pero también puede ser cualquier tipo de sistema externo.
y Algunos tipos de actores:
x Papeles que desempeñan las personas.
x Sistemas de computo.
x Aparatos electrónicos o mecánicos.
UTFSM
EXUMBRA
IN

Errores comunes con los casos de uso
z Un error común en la identificación de los casos de uso

consiste en representar los pasos, las operaciones o las
transacciones individuales como casos.
y Por ejemplo, podemos definir (incorrectamente) un caso
denominado "imprimir recibo", cuando en realidad esta operación
no es más que un paso de un proceso más amplio del caso
"comprar productos".
z Un caso de uso es una descripción de un proceso de
principio a fin relativamente amplia, descripción que suele
abarcar muchos pasos o transacciones; normalmente no es
un paso o una actividad individual del proceso.
UTFSM
EXUMBRA
IN
18
Identificación de casos de uso
z Los siguientes pasos de la identificación de los casos de

uso requieren de una lluvia de ideas y revisión exhaustiva
de los documentos actuales sobre la especificación de
requerimientos.
y Un método de identificación de los casos de uso se basa en
actores.
x 1. Se identifican los actores relacionados con un sistema o empresa.
x 2. Para cada actor se identifican los procesos que inician o en los
cuales participan.
y Otro método de identificación de casos de uso se basa en eventos.
x 1. Se identifican los eventos externos a los que un sistema ha de
responder.
x 2. Se relacionan los eventos con los actores y con los casos de uso.
UTFSM
EXUMBRA
IN

Identificación de casos de uso
z En la aplicación de punto de venta, algunos actores

posiblemente relevantes y los procesos que inician son:
y Cajero
x registra
x entrega el efectivo
y Cliente
x compra productos
x paga productos
UTFSM
EXUMBRA
IN
19
Casos de uso, funciones del sistema y trazabilidad
z Las funciones del sistema identificadas durante la

especificación previa de requerimientos deben asignarse a
los casos de uso.
y Además, debe ser posible verificar, mediante la sección de

referencias cruzadas, que todas las funciones hayan sido
asignadas.
UTFSM
EXUMBRA
IN

Diagramas de casos de uso
z Un diagrama de casos de uso explica gráficamente un

conjunto de casos de uso de un sistema, los actores y la
relación entre estos y los casos de uso.
y Diagrama parcial del ejemplo
Cajero Cliente
Comprar productos
UTFSM
EXUMBRA
IN
20
Clasificación de casos de uso
z Los casos de uso deberían clasificarse en primarios,

secundarios y opcionales para asignarles la prioridad de
desarrollo.
y Los casos de uso primarios representan los procesos comunes más
importantes, como Comprar productos.
y Los casos secundarios de uso representan procesos menores o
raros; por ejemplo, Solicitud de surtir un nuevo producto.
y Los casos opcionales de uso representan procesos que pueden no
abordarse.
UTFSM
EXUMBRA
IN

z Los casos esenciales de uso son casos expandidos de que

se expresan en una forma teórica que contiene poca
tecnología y pocos detalles de implementación; las
decisiones de diseño se posponen y se abstraen de la
realidad, especialmente en lo concerniente a la interfaz
usuaria.
y Retiro de efectivo es un ejemplo de caso de uso esencial.

1. El cliente se identifica. 2. Presenta opciones.
3. ….. 4. …
UTFSM
EXUMBRA
IN
21
z En cambio un caso de uso real describe concretamente el

proceso a partir de su diseño concreto actual, sujeto a las
tecnologías especificas de entrada y salida, etc.
y Cuando se trata de la interfaz usuaria a menudo ofrece
presentaciones de pantalla y explica la interacción con los
artefactos.

1. El cliente introduce su tarjeta. 2. Pide la clave personal (CP).
3. Introduce la clave con un teclado 4. Muestra menú de opciones.
numérico.
5. … 6. …
UTFSM
EXUMBRA
IN

Sobre la notación
z Al caso de uso se le asigna un nombre que comience con

un verbo para subrayar que se trata de un proceso. Por
ejemplo, “Comprar productos”, “Introducir pedidos”.
z Comience un caso de uso expandido con la siguiente

oración:
y Este caso de uso comienza cuando <Actor> <inicia un evento>
z De este modo se estimula una identificación clara del

actor y del evento iniciadores.
UTFSM
EXUMBRA
IN
22
Sobre la notación
z Un caso de uso puede contener puntos de decisión.

y Por ejemplo, en Comprar productos, el cliente puede optar al pago
en efectivo, a crédito o con cheque al momento de pago.
z Si una de estas trayectorias es un caso significativo y si las

otras alternativas son raras, inusuales o excepcionales, el
caso típico deberá ser el único acerca del cual se escribe el
curso normal de eventos y las opciones han de escribirse
en la sección titulada Alternativas.
UTFSM
EXUMBRA
IN

Sobre la notación
z Pero en ocasiones el punto de decisión representa

opciones cuya probabilidad es relativamente igual y
normal; en este caso se utiliza la siguiente estructura
notacional:
1. En la sección curso normal de eventos, indique las ramas de las
subsecciones.
2. Escriba una subsección en cada rama, utilizando otra vez el curso
normal de eventos. Inicie el evento numerando en 1 en cada
sección.
3. Si las subsecciones tienen opciones, escríbalas en una sección de
alternativas de cada subsección.
UTFSM
EXUMBRA
IN
23
Ejemplo de Punto de Ventas
Puntos de decisión
Sección: principal.
Curso normal de eventos
Cliente llega a una caja de TPDV (Terminal
de Punto de Ventas) con productos que
desea comprar.
2. El Cajero registra la identificación de cada 3. Determina el precio del producto e
producto. incorpora a la transacción actual la
Si hay varios productos de una misma información correspondiente.
categoría, el Cajero también puede introducir Se presentan la descripción y el precio del
la cantidad. producto actual.
Cajero indica a TPDV que se concluyó la
UTFSM
EXUMBRA
IN

Puntos de decisión
6. El cliente escoge el tipo de pago
a. Si paga en efectivo, consúltese la sección
de Pago en efectivo.
b. Si paga a crédito, consúltese la sección
Pago con tarjeta de crédito.
c. Si paga con cheque, consúltese la
sección Pago con cheque.
7. Registra la venta terminada
8. Imprime un recibo.
9. El Cajero le entrega al Cliente el recibo
impreso.
comprados.
Cursos alternativos
UTFSM
EXUMBRA
IN
24
Puntos de decisión
Sección: Pago en efectivo
Curso normal de eventos
Acción del actor Respuesta del sistema
1. El Cliente efectúa el pago en efectivo – el
2. El Cajero registra la cantidad de efectivo 3. Muestra al cliente la diferencia.
recibida.
4. El Cajero deposita el efectivo recibido y
extrae el cambio de pago.
El Cajero le da al Cliente el cambio.
Cursos alternativos
Sección: Pago con tarjeta de crédito

Cursos normales y alternativos de la historia de pago con la tarjeta de crédito.
Sección: Pago con cheque

Cursos
UTFSM normales y alternativos de la historia de pago cheque.
EXUMBRA
IN

Pasos de especificación de casos de uso
1. Después de haber listado las funciones del sistema, identifique los

actores y los casos de uso.
2. Escriba todos los casos de uso de alto nivel. Clasifíquelos en primarios,
secundarios u opcionales.
3. Dibuje un diagrama de caso de uso.
4. Escriba en el formato esencial expandido los casos de uso más
importantes, influyentes y riesgosos, a fin de entender y estimar mejor
la naturaleza y las dimensiones del problema. Para evitar casos
complejos posponga la escritura de la forma esencial expandida de los
casos de uso menos importantes hasta los ciclos de desarrollo futuros.
UTFSM
EXUMBRA
IN
25
Pasos de especificación de casos de uso
5. En teoría, los casos reales deberían posponerse hasta una fase de

diseño en el ciclo de desarrollo, porque su creación conlleva muchas
decisiones de diseño. Pese a ello, a veces es necesario crear casos
reales de uso durante la etapa inicial de los requerimientos en el caso
de que las descripciones concretas facilitan notablemente la
comprensión; los clientes exigen especificar los procesos de este
forma.
6. Clasifique los casos de uso.
UTFSM
EXUMBRA
IN

Clasificación y programación de los casos de uso
z Suponiendo que todos los artefactos deseados hayan sido

generados (por ejemplo, la especificación de los
requerimientos y los casos de uso), el siguiente paso es
iniciar la fase de construcción en el ciclo de desarrollo
iterativo y comenzar a implementar el sistema.
z En un ciclo de desarrollo iterativo, la tarea de llenar los

casos de uso se distribuye entre varios ciclos.
UTFSM
EXUMBRA
IN
26
Resumen
z Especificación de Requerimientos
z Casos de Uso: Descripción de Proceso
z Clasificación de los casos de uso
z Inicio de un ciclo de desarrollo
UTFSM
EXUMBRA
IN

Quiz
z ¿Qué son los requerimientos?

z ¿Qué relación tienen los requerimientos con las funciones y
los atributos del sistema?
z ¿Porqué las funciones se organizan en orden lógico?
z ¿Para qué definir la relación entre atributos y funciones?
z ¿Qué es un caso de uso?
z ¿Qué representa un diagrama de casos de uso?
z ¿Qué relación tienen los casos de uso con las funciones del
sistema?
UTFSM
EXUMBRA
IN
27
Quiz
z Interprete el siguiente diagrama de casos de uso.
<<se comunica con>>

seleccionar cursos a impartir
Estudiante
registrarse en cursos Profesor
<<usa>>
<<usa>>
crear lista de cursos
Valida usuario
S. Facturación
mantener inf profesor

mantener inf estudiante
mantener inf curso
UTFSM crear catalogo curso

EXUMBRA
IN
SOLEM Fundamentos de Ingeniería de SW
Secretario 55

Contenido
z Dependencia de los artefactos

z Técnicas de clasificación de casos de uso
z Formato extendido de los casos de uso
z Análisis Orientado a Objetos
y Modelo conceptual
y Formas de determinar conceptos
UTFSM
EXUMBRA
IN
28
z La estrategia general consiste en escoger primero los

casos que influyen profundamente en la arquitectura
básica. Las cualidades de un caso de uso así son los
siguientes:
y Tener una fuerte repercusión en el diseño arquitectónico; por
ejemplo, incorporar muchas clases a la capa del dominio o requerir
servicios de persistencia.
y Con relativamente poco esfuerzo obtener información e ideas
importantes sobre el diseño.
y Incluir funciones riesgosas, urgentes o complejas.
y Requerir una investigación a fondo o tecnología nueva o riesgosa.
y Representar los procesos primarios de la línea de negocios.
y Apoyar directamente el aumento de ingresos o la reducción de
costos.
UTFSM
EXUMBRA
IN

z Un sistema simple y poco riguroso puede servir para

realizar la clasificación: alto-mediano-bajo.
z Otro sistema es asignar un puntaje y sumar (posiblemente
con ponderación) para obtener una calificación.
Caso de uso a b c d e f Suma

Comprar productos 5 3 2 0 5 3 18
Y así sucesivamente
UTFSM
EXUMBRA
IN
29
z Con base a los criterios expuestos anteriormente, he aquí

un ejemplo de clasificación de algunos casos de uso en la
aplicación de punto de venta.
Clasificación Caso de uso Justificación

Alto Comprar productos Corresponde a los criterios de calificación más
altos.
Mediano Incorpora usuarios Afecta el subdominio de seguridad.
Registra los productos comprados Afecta el subdominio de seguridad.
Paga los productos comprados Proceso importante, afecta a contabilidad.
Bajo Pagar Efecto mínimo en la arquitectura.
Iniciar La definición depende de los otros casos de uso.
Cerrar Efecto mínimo en la arquitectura
UTFSM
EXUMBRA
IN

z Prácticamente todos los sistemas cuentan con un caso de

arranque o inicio.
y Aunque este no ocupe un nivel alto conforme a otros criterios, es
preciso estudiar al menos una versión simplificada de él al
comienzo del ciclo de desarrollo para presentar la inicialización
supuesta en otros casos.
UTFSM
EXUMBRA
IN
30
z A partir de la clasificación, el Caso de uso Comprar

productos debería incluirse en el primer ciclo de desarrollo,
también puede abordarse una versión simple de Inicio
para soportar los otros casos de uso.
z Siempre que se asigne un caso de uso, es necesario

estimar si es posible resolverlo íntegramente en el lapso
limitado de un ciclo (cuatro semanas, por ejemplo) o si el
trabajo ha de ser distribuido en varios ciclos.
UTFSM
EXUMBRA
IN

z En esta situación, el caso de uso se redefine, como por

ejemplo:
y Comprar productos versión 1 (pagos en efectivo, sin
actualizaciones de inventario, …)
y Comprar productos versión 2 (permitir cualquier tipo de pago)
y Comprar productos versión 3 (completa, con actualizaciones del
inventario, etc.)
z Las versiones anteriores se distribuyen después a lo largo
de una serie de ciclos de desarrollo junto con otros casos
de uso.
UTFSM
EXUMBRA
IN
31
Asignación de casos de uso a ciclos de desarrollo
z Si nos basamos en la clasificación de los casos y de varias

versiones de Comprar productos, podríamos asignar
algunos ciclos al ciclo de desarrollo:
y Ciclo de desarrollo 1: Comprar productos versión 1, …

y Ciclo de desarrollo 4: Registrar productos comprados, …, Pagar los
productos comprados, …
UTFSM
EXUMBRA
IN

Versiones de caso de uso Comprar Productos
z Una vez que se ha decidido simplificar los casos de uso y

expresarlo, hay que escribir versiones cada vez más
complejas.
z También hay que especificar las simplificaciones, las metas

y las suposiciones de cada versión.
UTFSM
EXUMBRA
IN
32
Versión 1 de Comprar Productos
z Simplificaciones, metas y suposiciones

y Pagos en efectivo exclusivamente
y Sin mantenimiento de inventario
y Es una tienda independiente, que no forma parte de ninguna
organización más grande.
y Captura manual del código universal de producto (CUP); sin lector
de código de barras.
y No se calculan los impuestos.
y Sin cupones de descuento.
y El cajero no tiene que registrar las ventas; no se controla el
acceso.
y No se lleva un registro de los clientes individuales ni de sus hábitos
de compra.
UTFSM
EXUMBRA
IN


y No se controla la caja de efectivo.
y En el recibo aparecen el nombre y la dirección de la tienda, la
fecha y la hora de la venta.
y Ni la identificación del cajero, ni la de TPDV aparecen en el recibo.
y Las ventas se registran en un documento histórico.
UTFSM
EXUMBRA
IN
33
Caso de uso: Comprar productos, versión 1

Propósito: Capturar una venta y su pago en efectivo.
Resumen: Un Cliente llega a la caja registradora con los artículos que comprará.
El Cajero registra los artículos y recibe una pago en efectivo. Al
terminar la operación, el Cliente se marcha con los artículos
comprados.
Tipo: Primario
Referencias Funciones: R1.1, R1.2, R1.3, R1.7, R2.1
Cruzadas:
UTFSM
EXUMBRA
IN

Curso normal de eventos:

Cliente llega a una caja de TPDV con
productos que desea comprar.
2. El Cajero registra el código universal de 3. Determina el precio del producto e
producto (CUP) en cada producto. incorpora a la transacción actual la
Si un producto se repite, el Cajero también información correspondiente.
puede introducir la cantidad. Presenta la descripción y el precio del
producto en cuestión.
Cajero indica a TPDV que se concluyó la
6. El Cajero indica el total al Cliente.
UTFSM
EXUMBRA
IN
34
7. El Cliente da un pago en efectivo – el

8. El Cajero registra la cantidad de efectivo 6. Muestra al cliente la diferencia.
recibida. Genera un recibo.
10. El Cajero deposita el efectivo recibido 11. Registra la venta concluida.
y extrae la diferencia.
El Cajero le entrega al Cliente el cambio y
el recibo impreso.
comprados.
Cursos alternativos
UTFSM
EXUMBRA
IN

Comprar Productos: versión 2

y Las simplificaciones de la versión 1 se aplican también en esta
versión salvo que el pago puede efectuarse en efectivo, con tarjeta
de crédito o con cheque. Las dos últimas formas de pago requieren
autorización.
Caso de uso: Comprar productos, versión 2

Propósito: Capturar una venta y su pago.
Resumen: Un Cliente llega a la caja registradora con los artículos que comprará.
El Cajero registra los artículos y recibe un pago, que puede requerir
una autorización. Al terminar la operación, el Cliente se marcha con
los artículos comprados.
UTFSM
EXUMBRA
IN
35
Análisis Orientado a Objetos
Inicio de un ciclo de desarrollo
z Suponga que la fase de planificación y elaboración ha

concluido y que los casos de uso han sido identificados,
clasificados y programados, por lo menos en los primeros
dos ciclos.
z Se presenta, entonces, una transición muy importante:
comienza la fase de construcción en la cual se cumplen los
ciclos de desarrollo iterativo.
UTFSM
EXUMBRA
IN

Inicio de un ciclo de desarrollo
z Las actividades iniciales del ciclo se relacionan con la

administración del proyecto.
y En el caso general, viene después (o, más probablemente, ocurre
en paralelo) una sincronización de la documentación a partir del
último ciclo con el estado real del código, porque los artefactos de
diseño y los códigos difieren invariablemente durante la fase de
codificación del último ciclo.
z Entonces empieza la fase de análisis, en la cual se
investiga a fondo los problemas del ciclo actual. En esta
fase, una de las actividades consiste en desarrollar el
modelo conceptual.
UTFSM
EXUMBRA
IN
36
Actividades
Perfeccionamie Sincronización Análisis Diseño Construcción Prueba

nto del plan de artefactos
1. Definir los 2. Perfeccionar 3. Perfeccionar 4. Perfeccionar

casos el diagrama de el modelo el glosario
esenciales casos conceptual
5. Definir 6. Definir los 7. Definir

diagramas de contratos de diagramas de
secuencia operaciones estado
UTFSM
EXUMBRA
IN

Artefactos
Casos de uso: Casos de uso Ventanas y Casos de

esenciales reales reportes prueba
expandidos
Diagramas de
casos de uso Diagramas de Métodos
interacción
Modelo
conceptual
Diagramas de Definicione
Glosario clase de s de clase y
diseño de interfaz
Diagramas de
secuencia del
sistema Diagrama de
paquete de
Contratos de arquitectura dependencia respecto a
operación
Diagramas de Esquema de SQL

estado base de
datos
UTFSM
EXUMBRA
IN
37
Construcción de un modelo conceptual
z Un modelo conceptual explica (a sus creadores) los

conceptos significativos en un dominio del problema, es el
artefacto más importante a crear durante el análisis
orientado a objetos
y los casos de uso son artefactos importantes pero no son realmente
orientados a objetos
UTFSM
EXUMBRA
IN

Construcción de un modelo conceptual
z Identificar muchos objetos o conceptos constituye la

esencia del análisis orientado a los objetos, y el esfuerzo
se compensa con los resultados conseguidos durante la
fase de diseño e implementación.
z Una cualidad esencial que debe ofrecer un modelo

conceptual es que representa cosas del mundo real, no
componentes del software.
UTFSM
EXUMBRA
IN
38
Fundamentos
z Los modelos conceptuales se representan en UML con un

grupo de diagramas de estructura estática donde no se
define ninguna operación.
z El modelo conceptual puede mostrarnos:
y conceptos
y asociaciones entre ellos
y atributos de conceptos
z Por ello los artefactos de software, como una ventana o
una base de datos, no forman parte del modelo
conceptual, salvo que el dominio a modelar se refiera a
conceptos de software; por ejemplo, un modelo de
interfaces gráficas.
UTFSM
EXUMBRA
IN

Fundamentos
z En términos informales el concepto es una idea, cosa u

objeto. En un lenguaje más formal podemos considerarlo a
partir de su símbolo, intensión y extensión:
y Símbolo: palabras o imágenes que representan un concepto.
y Intensión: la definición de un concepto.
y Extensión: el conjunto de ejemplos a que se aplica el concepto.
z Concepto del evento de una transacción de compra
y Podemos optar por designarlo con el símbolo Venta.
y La intensión de Venta puede afirmar que “representa el evento de
una transacción de compra y tiene fecha y hora”.
y La extensión de Venta son todos los ejemplos de venta; en otras
palabras, el conjunto de todas las ventas.
UTFSM
EXUMBRA
IN
39
Fundamentos
z Modelos conceptuales y la descomposición

y Los problemas de software a veces son complejos; la
descomposición – divide y vencerás – es una estrategia que suele
utilizarse para resolver el problema de complejidad dividiendo el
espacio del problema en unidades comprensibles.
y Por tanto, la tarea primordial de análisis consiste en identificar los

conceptos en el dominio del problema y documentar los resultados
en un modelo conceptual.
UTFSM
EXUMBRA
IN

Fundamentos
z Por ejemplo, en el dominio del problema real en una tienda

con un terminal de punto de venta intervienen los
conceptos de:
y Tienda
y TPDV
y Venta
z Por tanto, el modelo conceptual debe incluir estos

conceptos.
UTFSM
EXUMBRA
IN
40
Estrategias para identificar los conceptos
z Objetivo: crear un modelo conceptual de objetos

representativos del dominio del problema.
z Directrices básicas:
y Es mejor exagerar y especificar un modelo conceptual con muchos
conceptos refinados que no especificarlo cabalmente.
x Es frecuente omitir conceptos durante la fase inicial de identificación y
descubrirlos más tarde cuando se examinen los atributos o
asociaciones o durante la fase de diseño. Cuando se detecten, habrá
que incorporarlos al modelo conceptual.
y Un concepto no debe ser excluido simplemente porque los
requerimientos no indican una necesidad evidente que permita
recordar la información acerca de ella (criterio común para diseñar
los bases de datos), o porque el concepto carezca de atributos.
UTFSM
EXUMBRA
IN

Estrategias para identificar conceptos: Lista de categorías
z La creación del modelo conceptual a partir de una lista de

categorías se comienza preparando una lista de conceptos
idóneos a partir de la siguiente lista. Contiene muchas
categorías comunes que vale la pena tener en cuenta, sin
que importe el orden de importancia.
z Categorías:
y objetos físicos o tangibles
x TPDV
x Avión
y especificaciones, diseño o descripciones de cosas
x Especificación De Producto
x Descripción De Vuelo
UTFSM
EXUMBRA
IN
41
z Categorías:
y lugares
x Tienda
x Aeropuerto
y transacciones
x Venta, Pago
x Reservación
y línea o renglón de elemento de transacciones
x Ventas Línea De Producto
y papel de personas
x Cajero
x Piloto
y contenedores de otras cosas
x Tienda, Cesto
x Avión
UTFSM
EXUMBRA
IN

z Categorías:
y otros sistemas de computo o electromecánicas externos al sistema
x Sistema De Autorización De Tarjeta De Crédito
x Control De Trafico Aéreo
y conceptos de nombres abstractos
x Hambre
x Acrofobia
y organizaciones
x Departamento De Ventas
x Objeto Línea Aérea
y eventos
x Venta, Robo, Junta
x Vuelo, Accidente, Aterrizaje
y procesos (a menudo no están representados como conceptos, pero
pueden estarlo)
x Venta De Producto
x Reservación Asiento
UTFSM
EXUMBRA
IN
42
z Categorías:
y reglas y políticas
x Política De Reembolso
x Política De Cancelaciones
y catálogos
x Catalogo De Producto
x Catalogo De Partes
y Registro de finanzas, de trabajo, de contratos, de asuntos legales
x Recibo, Contrato De Empleo
x Bitácora De Mantenimiento
y instrumentos y servicios financieros
x Línea De Crédito
x Existencia
y manuales, libros
x Manual De Personal
x Manual De Reparaciones
UTFSM
EXUMBRA
IN

Obtención de conceptos a partir de frases nominales
z Otra técnica muy útil (por su simplicidad) consiste en

identificar las frases nominales (sustantivos) en las
descripciones textuales del dominio de un problema y
considerarlas conceptos o atributos idóneos.
z Este método hay que usarlo con prudencia, ya que no es
posible encontrar mecánicamente correspondencias entre
sustantivo y concepto, y además las palabras del lenguaje
natural son ambiguas.
z Pese a ello esta técnica es muy útil cuando se empieza a
entender el enfoque de orientación a objetos.
UTFSM
EXUMBRA
IN
43

Cliente llega a una caja de TPDV con
productos que desea comprar.
2. El Cajero registra el código universal 3. Determina el precio del producto e
de producto (CUP) en cada producto. incorpora a la transacción actual la
Si un producto se repite, el Cajero información correspondiente.
también puede introducir la cantidad. Presenta la descripción y el precio del
producto en cuestión.
UTFSM
EXUMBRA
IN

z Algunas de las frases marcadas son conceptos idóneos,

algunas pueden ser atributos de conceptos. El consejo es
combinar este método con la lista de categorías.
UTFSM
EXUMBRA
IN
44
Resumen
z Dependencia de los artefactos

z Técnicas de clasificación de casos de uso
z Formato extendido de los casos de uso
z Análisis Orientado a Objetos
y Modelo conceptual
y Formas de determinar conceptos
UTFSM
EXUMBRA
IN

Resumen
z ¿Porqué se clasifican los casos de uso?

z ¿Qué es un caso de uso inicio?
z ¿Porqué es necesario simplificar un caso de uso?
z ¿Qué significaría que un artefacto no dependa de otros?
z ¿Qué representa el modelo conceptual y cómo se obtiene?
UTFSM
EXUMBRA
IN
45
Contenido
z Identificación de conceptos
y Ejemplo
z Principio del cartógrafo
z Asociaciones de conceptos
z Identificación de atributos
z Construcción del modelo conceptual
UTFSM
EXUMBRA
IN

Ejemplo: Obtención de conceptos
z En el caso de punto de venta, los conceptos identificados

son los siguientes:
y TPDV, Producto, Tienda, Venta, Pago
y Catalogo De Productos, Especificación De Producto
y Ventas Línea De Productos
y Cajero, Cliente, Gerente
z ¿Se debe o no incluir el recibo?
UTFSM
EXUMBRA
IN
46
Obtención de conceptos
z El recibo es un registro de venta y de un pago, así como el

concepto relativamente prominente en el dominio de
ventas: ¿debe entonces, mostrarse en el modelo?
y El recibo es un informe de venta, toda su información proviene de
otra parte. Este es un buen motivo para excluirlo.
y El recibo cumple un papel esencial respecto a las reglas de la
empresa: el portador le confiere el derecho de devolver los
productos adquiridos. Esta es la razón para incluirlo en el modelo.
z El recibo se excluirá por el momento, porque las
devoluciones de productos no están incorporados en este
ciclo de desarrollo.
UTFSM
EXUMBRA
IN

Directrices para construir modelos conceptuales
z Aplique los siguientes pasos para construir un modelo

conceptual:
y Liste los conceptos idóneos usando la lista de categoría de
conceptos y la identificación de frases nominales relacionadas con
los requerimientos en cuestión.
y Dibújelos en el modelo conceptual.
y Incorpore las asociaciones necesarias para registrar las relaciones
entre los conceptos.
y Agregue los atributos necesarios para cumplir con las necesidades
de la información.
UTFSM
EXUMBRA
IN
47
Directrices: El cartógrafo
z La estrategia del cartógrafo se aplica a los mapas y a los

modelos conceptuales:
y Utilice los nombres existentes en el dominio.
y Excluya las características irrelevantes.
y No agregue cosas que no existan.
UTFSM
EXUMBRA
IN

Directrices: El cartógrafo
z Los cartógrafos se sirven de los nombres del territorio – no cambian

los nombres de ciudades en sus mapas. En el caso de un modelo
conceptual ello significa utilizar el vocabulario del dominio cuando se
asignan nombres a los conceptos y a los atributos.
z Un cartógrafo elimina cosas en el mapa en caso de que no las juzgue
pertinentes para el propósito: por ejemplo, excluir la información sobre
la población. De modo similar, un modelo conceptual puede excluir los
conceptos que no estén relacionados directamente con los
requerimientos.
z Un cartógrafo no muestra cosas en el mapa que no existan. En forma
parecida, el modelo conceptual no debe mostrar las cosas que no se
encuentren en el dominio del problema en cuestión.
UTFSM
EXUMBRA
IN
48
Un error frecuente al identificar conceptos
z Tal vez, el error más frecuente cuando se crea el modelo

conceptual es el de representar algo como atributo,
cuando debió haber sido un concepto.
z Una regla práctica de no caer en él:
y Si en el mundo real no consideramos algún concepto X como
número o texto, probablemente X sea un concepto y no un
atributo.
x Por ejemplo, en el dominio de reservaciones en líneas aéreas: ¿debería
el aeropueto de destino ser atributo de vuelo o un concepto aparte?
En el mundo real, un aeropuerto de destino no se considera ni
número, ni texto, es una cosa que ocupa espacio. Por tanto,
Aeropuerto debería ser un concepto.
y En caso de duda, convierta un atributo en un concepto.
UTFSM
EXUMBRA
IN

Agregación de las Asociaciones
z Es necesario identificar las asociaciones de los conceptos

que se requieren para satisfacer los requerimientos de
información de los casos de uso en cuestión y los que
contribuyen a entender el modelo conceptual.
z La asociación es una relación entre dos conceptos que
indica alguna conexión significativa entre ellos.
z En el lenguaje UML se describen como relaciones
estructurales entre los objetos de diferentes tipos.
UTFSM
EXUMBRA
IN
49
Agregación de Asociaciones : Criterios
z Las asociaciones que vale la pena mencionar suelen incluir

el conocimiento de una relación que ha de preservarse
durante algún tiempo: puede tratarse de milisegundos o
años según el contexto.
TPDV Venta actual

1 Registra 1
Asociación
UTFSM
EXUMBRA
IN

Agregación de las Asociaciones : Criterios
z Examine la conveniencia de incluir las siguientes

asociaciones en un modelo conceptual:
y Las asociaciones en que el conocimiento de la relación ha de ser
preservado durante algún tiempo (asociaciones que deben
“conocerse”)
y Las asociaciones provenientes de la lista de asociaciones comunes.
x Por ejemplo, las instancias de VentaLineaDeProducto deben ir
asociadas a la instancia Venta, sin esto sería imposible imprimir un
recibo, calcular el total, etc.
x En cambio, no necesitamos una relación entre Gerente y Venta.
UTFSM
EXUMBRA
IN
50

Parte 2

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Parte 2

Cargado por

Copyright:

Formatos disponibles

Introducción al proceso de desarrollo

Fase de construcción: ciclos de desarrollo

z La fase de construcción de un proyecto requiere varios

z En un ciclo individual de desarrollo, los principales pasos se

Introducción al proceso de desarrollo

Ciclo de Ciclo de Ciclo de

Perfeccionami Sincronización Análisis Diseño Construcción Prueba

1. Definir casos 2. Perfeccionar 3. Perfeccionar 4. Perfeccionar

5. Definir 6. Definir los 7. Definir

z Como en el caso de los artefactos de la fase de

y Modelo conceptual y glosario.

Introducción al proceso de desarrollo

z El modelo conceptual es una representación de conceptos

z Debe limitarse el esfuerzo aplicado a la creación de un

z La estrategia recomendada es generar rápidamente un

z Otra estrategia es suspender la creación de un modelo

Introducción al proceso de desarrollo

z Durante la fase de planificación y elaboración, se aconseja

z Por lo tanto se recomienda estudiar detenidamente,

z UML describe modelos de sistema basado en los conceptos

z Todos los diagramas de UML pueden ser divididos en dos

Introducción al proceso de desarrollo

z El modelo global del sistema esta constituido por:

z Modelo de análisis: el que se relaciona con una

z Modelo de diseño: el que se relaciona con la solución

z Sin importar como los artefactos se organicen para

z Si se crea un artefacto que no tenga otros dependientes y

Introducción al proceso de desarrollo

Análisis y diseño orientado a objetos

z ¿Cuál es la diferencia entre análisis y diseño OO?

Fase de planificación y elaboración

z Con esta actividad se quieren lograr los siguientes

z Requerimientos son una descripción de necesidades o

Fase de planificación y elaboración

z Declaración general: el propósito de este proyecto es crear un sistema

z Funciones del sistema son aquellas que el sistema se

Fase de planificación y elaboración

z En cambio, los atributos del sistema son cualidades no-

y Nótese que facilidad de uso no encaja en la oración de verificación:

z Las funciones deben ser clasificadas en categorías para

z Las categorías incluyen:

Fase de planificación y elaboración

z Las siguientes funciones básicas del sistemas en la

Ref # Función Categoría

z Sería mejor agrupar funciones en un orden lógico, por

Ref # Función Categoría

Fase de planificación y elaboración

z Los atributos del sistema son características o dimensiones

z Los atributos tienen un posible conjunto de detalles de

z Algunos atributos del sistema también pueden tener

Atributo Detalle y limitación

Fase de planificación y elaboración

z Atributos del sistema en especificaciones de las funciones

Ref# Función Categ. Atributo Detalles y Categ.

y Identificar y escribir casos de uso

Fase de planificación y elaboración

z La técnica de casos de uso se puede aplicar tanto al

z Un caso de uso es un documento narrativo que describe la

Fase de planificación y elaboración

z Un caso de uso expandido muestra más detalles que uno

Caso de uso: Comprar productos en efectivo

Acción de los actores Respuesta del sistema