0% encontró este documento útil (0 votos)
333 vistas129 páginas

Taller de Proyectos Software

Descargar como pdf o txt
Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1/ 129

Universidad de Tarapacá

Área de Ingeniería en Computación e Informática


Marco Villalobos Abarca

TALLER DE PROYECTOS SOFTWARE


UN PROCESO SOFTWARE BASADO EN
UML
PARA SISTEMAS DE INFORMACIÓN
CONTENIDOS

 Introducción
 Modelo del Negocio

 Modelo de Requisitos

 Modelo de Análisis

 Modelo del Diseño


CONSTRUIR SOFTWARE ES DIFÍCIL

Método
MÉTODO

 Establece cómo abordar de un modo sistemático


la construcción de software.
 Se describe el problema y la solución mediante un
conjunto de modelos.
 Los métodos ayudan pero no aseguran el éxito.
 Un método es fruto de la experiencia.
 Importante conocer las limitaciones de un método.
MÉTODO

TECNOLOGIA
(OO, UML)

ORGANIZACION PROCESO
(UTA) (Rational Unified Process: RUP)
TECNOLOGÍA

 Conceptos
 Orientación a objetos
 Diseño estructurado

 Notación
 Especificaciones formales
 Plantillas

 Diagramas
PROCESO SOFTWARE

“Un proceso bien definido es necesario para


desarrollar sistemas software de manera
repetible y predecible”

“Permite un negocio sostenible y que puede


mejorar en cada nuevo proyecto, incrementando
la eficiencia y productividad de la organización”

G. Booch
PROCESO SOFTWARE

 Un proceso software debe especificar:

 la secuencia de actividades a realizar por el equipo


de desarrollo: flujo de actividades
 productos que deben crearse: qué y cuándo

 asignación de tareas a cada miembro del equipo y


al equipo como un todo
 criterios para controlar el proceso
PROCESO SOFTWARE

Basados en casos de uso.


Debe ser iterativo e incremental.
 Conviene centrarse en los aspectos críticos en las
primeras iteraciones para minimizar riesgos.
 Rápida retroalimentación
 Establecer un proceso marco: “Cada empresa
de desarrollo debe crearse su propio proceso”.
UN PROCESO SIMPLE

 Simple, eficaz y pequeño: fácil de aprender y usar.


 Se añade al proceso de Craig Larman (“UML y
Patrones”, Prentice-Hall, 2002) una etapa de
modelado del negocio.
 Útil para pequeños y medianos proyectos y para
un primer proyecto OO.
 Dirigido por los casos de usos.
 Desarrollo iterativo e incremental.
ETAPAS DEL PROCESO

 Inicio
 Comprender procesos del negocio.
 Obtener y especificar requisitos del sistema.
 Identificar y especificar clases y colaboraciones
para objetos del dominio (análisis).
 Resolver problemas de diseño (arquitectura, base
de datos, redes, patrones, nuevas clases y
colaboraciones,..).
 Implementación.
 Validación.
ETAPAS DEL PROCESO

 Situación Actual
 Modelado del Negocio

 Modelado de Requisitos

 Modelado del Análisis

 Modelado del Diseño

 Implementación

 Validación
ETAPA INICIAL (1)

 Estudio de necesidades de la empresa, ver si es


viable, alternativas, análisis de riesgos,
oportunidad.
 Definición de objetivos del proyecto.
 Estimación aproximada del coste.

¿Debemos abordar el proyecto?


ETAPA INICIAL (2)

 Primeros talleres de requisitos.


 Plan para la primera iteración.
 Casos de uso escritos en formato breve, excepto
unos pocos que se consideran claves.
 Se identifican riesgos.
 Escribir borrador del documento Visión y
Especificación Preliminar.
 Prototipado.
MODELADO DEL NEGOCIO
Objetivo:
Comprender el conjunto de procesos de negocio que
tienen lugar dentro de una empresa, como paso previo
a establecer los requisitos del sistema a desarrollar.
Ejemplo de procesos de negocio:
 Empresa que fabrica productos bajo demanda

Registrar Fabricar Gestionar Realizar


pedido de productos almacén de pedidos a
cliente pedidos materiales proveedores

¿Cómo consigue la empresa sus objetivos?


PROCESOS DE NEGOCIO

 Una organización tiene una serie de objetivos que


satisface a través de Procesos de Negocio
 Elementos de un proceso de negocio:
 Flujo de Tareas, Agentes, Información y Reglas Negocio
 Reglas de Negocio regulan el funcionamiento de la
empresa
 Describen restricciones y comportamientos
 NO son requisitos, pero influyen en ellos
REGLAS DEL NEGOCIO
• Determinan políticas y estructura de la información
• Restricciones que afectan a las informaciones y acciones de la organización a la hora
de realizar una determinada actividad.
• También pueden aparecer asociadas a una información, como restricciones de
integridad.

Ejemplos:
Sistema de tutoría WEB.

• Horas de tutoría del profesor >= 6.


• Un usuario no puede fallar durante el proceso de identificación más de 3 veces.

Sistema Centro Comercial Virtual: proceso de negocio: pedidos.

• Cuando se realice un pedido a un proveedor debe especificarse la cantidad


necesaria para llegar al nivel normal de stock a partir de la cantidad actual.
• Deberá evitarse la duplicidad de pedidos. No deben existir dos pedidos a
proveedor para un mismo producto.
• Cuando aparezca un conflicto con algún pedido de un cliente, el responsable de
abastecimiento deberá consultar con el asociado la forma de resolver el
conflicto: esperar a que lleguen los productos, según su frecuencia de
distribución, o realizar un pedido especial.
PROCESOS Y REGLAS DEL NEGOCIO

Procesos del Negocio


RN1
datos
tarea2 RN3
tarea1 tarea4 tarea5
tarea3

Reglas del Negocio RN2

Determinan políticas y estructura de la información


EJEMPLO
EMPRESA QUE FABRICA PRODUCTOS BAJO DEMANDA

Objetivos
Estratégicos
Satisfacer pedido Incrementar las Reducir tiempo de
...
de cliente ventas un 25% fabricación un 15%

Subobjetivos
Procesos del
Negocio Registrar Fabricar Gestionar Realizar
pedido de productos almacén de pedidos a
cliente pedidos materiales proveedores
Casos de Uso
del Negocio
Generar
Registrar Fabricar Gestionar pedidos a
pedido productos almacén proveedor
ETAPAS DEL MODELADO DEL NEGOCIO

 Identificar y definir los procesos de negocio según los


objetivos de la organización.
 Definir un caso de uso del negocio para cada proceso del
negocio (diagrama de casos de uso del negocio puede
mostrar el contexto y los límites de la organización).
 Identificar los roles implicados en los diferentes procesos
del negocio (diagrama de roles).
ETAPAS DEL MODELADO DEL NEGOCIO

 Modelar el flujo de tareas asociado a cada proceso de


negocio mediante escenarios (diagramas de secuencia)
y diagramas de procesos (diagramas de actividades)
que muestran la interacción entre roles para conseguir
el objetivo.

 Especificar las informaciones y actividades incluidas en


cada diagrama de actividades.
DIAGRAMA CASOS DE USO DEL NEGOCIO

<<initiator>>

Registrar pedido
Cliente

Fabricar producto

Gestionar almacén

Generar pedidos a proveedores Proveedor


DESCRIPCIÓN DE
CASOS DE USO DEL NEGOCIO

 Textual
 Visual
 Diagrama de Roles:
aspecto estructural de colaboración entre roles
 Escenario:
aspecto de comportamiento de la colaboración
 Diagrama de Proceso:
workflow que realiza el caso de uso del negocio
CASO DE USO DEL NEGOCIO:
“REGISTRAR PEDIDO”

1. El cliente realiza un pedido que incluirá la fecha del pedido, los datos
del cliente y los productos solicitados.

2. El comercial revisa el pedido (completándolo si es necesario) y le da


curso, enviándolo al jefe técnico para que realice el análisis del mismo.

3. El jefe técnico analiza la viabilidad de la fabricación de cada producto


del pedido por separado.
- si el producto pedido está en el catálogo, se acepta la fabricación del
mismo,
- en caso contrario, el producto es especial, y el jefe técnico estudia su
fabricación
- si ésta es viable, la fabricación del producto especial es aceptada,
- si no es viable, el producto no será fabricado.
CASO DE USO DEL NEGOCIO:
“REGISTRAR PEDIDO”

4. Una vez estudiado el pedido completo, el jefe técnico


- informa al departamento comercial de la aceptación/rechazo de cada
producto integrante del pedido.
- si todos los productos de un pedido han sido aceptados, genera una orden
de trabajo para cada producto, a partir de una plantilla de fabricación (la
estándar, si el producto estaba catalogado, o bien una nueva generada
para el producto, si éste estaba fuera del catálogo). Cada orden de trabajo
es enviada al jefe de producción, y queda pendiente de su lanzamiento.

5. El comercial comunica al cliente el resultado del análisis de su pedido.


PLANTILLA DE DESCRIPCIÓN “REGISTRAR
PEDIDO”
Proceso de
Registrar Pedido
Negocio
Objetivo Registrar Pedido de Cliente
Descripción 1. El cliente envía una orden de pedido, que debe incluir la fecha de solicitud, datos del
cliente y productos solicitados. Es posible que sea un empleado del departamento comercial
quien introduzca el pedido, a petición de un cliente que realizó su pedido por teléfono o lo
envió por fax o correo ordinario al dpto. comercial de la empresa.
2. El empleado revisa el pedido (completándolo, si es necesario), y comienza su
procesamiento enviándolo al jefe técnico, encargado de su análisis.
3. El jefe técnico analiza la viabilidad de cada producto pedido por separado:
Si el producto pedido está en el catálogo, su fabricación es aceptada.
En caso contrario es considerado un producto especial y estudia su producción:
- Si es viable, la fabricación del producto especial es aceptada;
- Si no es viable, el producto especial no será fabricado.
4. Una vez estudiado el pedido completo, el jefe técnico...
Informa al depto comercial de la aceptación o rechazo de cada producto pedido;
Si todos los productos de un pedido han sido aceptados, se crea una orden de trabajo
para cada producto, a partir de una plantilla de fabricación (la estándar si el producto
estaba catalogado, o una nueva, específicamente diseñada para el producto, si éste no
estaba en el catálogo). Cada orden de trabajo es enviada al jefe de producción, y queda
pendiente de su lanzamiento.
5. El comercial comunica al cliente el resultado final del análisis de su pedido.
Prioridad Básico
Riesgos ...
Posibilidades ...
Tiempo Ejec. ...
Coste Ejec. ...
PLANTILLA DE DESCRIPCIÓN “REGISTRAR
PEDIDO”
Proceso de
Registrar Pedido
Negocio
Objetivo Registrar Pedido de Cliente
Descripción Rol Externo
1. El cliente envía una orden de pedido, que debe incluir la fecha de solicitud, datos del
cliente y productos solicitados. Es posible que sea un empleado del departamento comercial
quien introduzca el pedido, a petición de un cliente que realizó su pedido por teléfono o lo
envió por fax o correo ordinario al dpto. comercial de la empresa.
2. El empleado revisa el pedido (completándolo, si es necesario), y comienza su
procesamiento enviándolo al jefe técnico, encargado de su análisis.
3. El jefe técnico analiza la viabilidad de cada producto pedido por separado:
Roles Internos
Si el producto pedido está en el catálogo, su fabricación es aceptada.
En caso contrario es considerado un producto especial y estudia su producción:
- Si es viable, la fabricación del producto especial es aceptada;
- Si no es viable, el producto especial no será fabricado.
4. Una vez estudiado el pedido completo, el jefe técnico...
Informa al depto comercial de la aceptación o rechazo de cada producto pedido;
Si todos los productos de un pedido han sido aceptados, se crea una orden de trabajo
para cada producto, a partir de una plantilla de fabricación (la estándar si el producto
estaba catalogado, o una nueva, específicamente diseñada para el producto, si éste no
estaba en el catálogo). Cada orden de trabajo es enviada al jefe de producción, y queda
pendiente de su lanzamiento.
5. El comercial comunica al cliente el resultado final del análisis de su pedido.
Prioridad Básico
Riesgos ...
Posibilidades ...
Tiempo Ejec. ...
Coste Ejec. ...
MODELADO DEL NEGOCIO

 Identificamos los agentes o roles participantes (En


el ejemplo: Cliente, Comercial, Jefe Técnico y Jefe
Producción ).
 Diagrama de Roles: diagramas de clase (clases son roles)
 Creamos escenarios para mostrar la colaboración
entre los agentes, distinguimos entre flujos básicos
y alternativos:
 Escenarios: diagramas de secuencia (objetos son roles)
Diagrama de roles “Registrar Pedido”

<<role>> <<role>>
Cliente Comercial

*
*

<<role>> <<role>>
Jefe Tecnico. Jefe Producción
Escenario “Registrar Pedido”

: Cliente : Comercial : JefeTecnico : JefeProduccion

darCursoPedido()
estudiarPedido()

* analizarFabricacionProducto()

planificarFabricacion()

informarAnalisisPedido()

aceptarPedido()
FLUJOS DE ACTIVIDADES

 Mostrar flujo del proceso mediante diagramas


de proceso
 diagramas de actividades con calles que
corresponden a roles
 Es posible que una actividad necesite ser
descrita mediante otro diagrama de actividad:
Objetivos y Subobjetivos.
 Pueden existir procesos de negocio que no
requieran interacción entre agentes.
DIAGRAMA DE PROCESO “REGISTRAR PEDIDO”
: Cliente : Comercial : JefeTecnico : JefeProduccion

:Catalogo
p: Pedido
Rellenar pedido [propuesto]

:Plantilla de
Fabricacion
Cursar pedido p: Pedido
[en_evaluacion]

Analizar viabilidad

p:Pedido
[evaluado]
: Producto
Especial
Notificar rechazo [ NO ] ¿Viable?
de pedido

[ SI ]
Fin KO
:Plantilla de
p: Pedido Fabricacion
[rechazado]

Notificar aceptación :Orden de


de pedido Trabajo
Ordenar fabricacion [pendiente]

Planificar produccion
p: Pedido
[aceptado]

Fin OK
DIAGRAMA DE PROCESO “REGISTRAR PEDIDO”

Demasiado compleja:
: Cliente : Comercial : JefeTecnico : JefeProduccion

:Catalogo

Rellenar pedido
p: Pedido
[propuesto] Descomposición
:Plantilla de
Fabricacion Jerárquica
Cursar pedido p: Pedido
[en_evaluacion]

Analizar viabilidad

p:Pedido
[evaluado]
: Producto
Especial
Notificar rechazo [ NO ] ¿Viable?
de pedido

[ SI ]
Fin KO
:Plantilla de
p: Pedido Fabricacion
[rechazado]

Notificar aceptación :Orden de


de pedido Trabajo
Ordenar fabricacion [pendiente]

Planificar produccion
p: Pedido
[aceptado]

Fin OK
REGLAS DEL NEGOCIO

 Reglas de restricción
 Especifican políticas o condiciones que restringen la
estructura y comportamiento de las informaciones
 Estímulo-Respuesta
 Restricción de operación

 Restricción de estructura

 Reglas de derivación
 Especifican políticas o condiciones para inferir nuevos
hechos a partir de otros.
GLOSARIO
... ...
Objeto de Información: Pedido Actividad: Ordenar fabricacion

Atributos Origen: Analizar viabilidad


Código de pedido Agente: Jefe Técnico
Fecha de solicitud Precondiciones: La fabricación de todos los productos
Fecha límite de entrega pedidos es viable. Existe una plantilla de fabricación para
Conjunto de {Producto} cada uno de dichos productos.
Cliente Postcondiciones: Ha sido creada una orden de trabajo para
Importe total cada producto, con estado pendiente, y ha sido enviada al
Estado Actual jefe de producción para su planificación.
Caso de Uso : - por especificar-
Restricciones
- El código de pedido identificará unívocamente el
pedido, y será asignado automáticamente por el
sistema Actividad: Notificar aceptacion de pedido
- La fecha de solicitud será anterior a la fecha límite de
entrega.
Origen: Analizar viabilidad
- Un pedido contendrá al menos un producto; no existe
Agente: Comercial
límite máximo de productos.
Precondiciones: La fabricación de todos los productos
- Un pedido siempre será solicitado por uno y pedidos es viable.
solamente un cliente. Postcondiciones: Se ha comunicad al cliente la aceptación
- El importe total será calculado a partir del precio de de su pedido. El estado del pedido es aceptado.
cada producto pedido.
Caso de Uso : - por especificar-
Clase del Dominio : - por especificar -


...
GLOSARIO
... ...
Objeto de Información: Pedido Actividad: Ordenar fabricacion Reglas de
Atributos
Estímulo-Respuesta
Origen: Analizar viabilidad
Código de pedido Agente: Jefe Técnico
Fecha de solicitud Precondiciones: La fabricación de todos los productos
Fecha límite de entrega pedidos es viable. Existe una plantilla de fabricación para
Conjunto de {Producto}
Cliente Reglas
cada uno de dichos productos. Reglas de
Postcondiciones: Ha sido creada una orden de trabajo para
Importe total
Estructurales, Operación
cada producto, con estado pendiente, y ha sido enviada al
Estado Actual jefe de producción para su planificación.

Restricciones de Derivación y Caso de Uso : - por especificar-

de
- El código de pedido identificará Existencia
unívocamente el
pedido, y será asignado automáticamente por el
sistema Actividad: Notificar aceptacion de pedido
- La fecha de solicitud será anterior a la fecha límite de
entrega.
Origen: Analizar viabilidad
- Un pedido contendrá al menos un producto; no existe
Agente: Comercial
límite máximo de productos.
Precondiciones: La fabricación de todos los productos
- Un pedido siempre será solicitado por uno y pedidos es viable.
solamente un cliente. Postcondiciones: Se ha comunicad al cliente la aceptación
- El importe total será calculado a partir del precio de de su pedido. El estado del pedido es aceptado.
cada producto pedido.
Caso de Uso : - por especificar-
Clase del Dominio : - por especificar -


...
ESPECIFICACIÓN DE LAS ACTIVIDADES

Contrato: nombre de la actividad realizada por los actores


Origen: Actividad/es precedente/s
Agente: Actor que realiza la actividad
Precondición: Estado previo a la realización de la actividad
Postcondición: Estado posterior a la realización de la actividad
Caso de uso: Nombre del caso de uso que se corresponde con
la actividad. Este campo no se rellenará hasta que no se
identifiquen los casos de uso.
ESPECIFICACIÓN DE LAS INFORMACIONES

Nombre de la información
Atributos: Listado de los atributos de la información
Restricciones: Restricciones sobre los atributos de la
información, referidas tanto al significado como al valor
de los mismos.
Clase: Nombre de la clase que modelará esta información.
En principio no se indica nada, y sólo se rellena este
campo cuando la clase es identificada en el modelado
conceptual.
MODELADO DE REQUISITOS

Objetivo:
Se establecen los requisitos funcionales y no
funcionales del sistema.

A partir del modelo del negocio (si se hace) se


construye el modelo de casos de uso y el modelo
conceptual.
TIPOS DE REQUISITOS

 Funcionales
 No Funcionales
 Usabilidad
 Fiabilidad
 Rendimiento
 Adaptabilidad, Mantenimiento, Configurable
 Implementación: lenguajes, herramientas,..
 GUI
 Legales
MODELADO DE REQUISITOS
 Extraer los casos de uso del sistema a partir de las
actividades que aparecen en los diagramas de
actividades.
 Establecer el modelo conceptual a partir de las
informaciones incluidas en los diagramas de
actividades.
 Agrupar casos de uso derivados de un diagrama de
procesos en un diagrama de casos de uso
MODELO DE REQUISITOS

 De los diagramas de proceso...

rol
actor
actividad Caso de Uso

objeto Clase del Dominio


MODELO DE REQUISITOS

 Se define un actor para cada rol del diagrama de


proceso que interacciona con el sistema: actor
primario.

 Se crea un caso de uso por cada actividad que es


soportada por el sistema: “Un caso de uso
produce un resultado de valor a un actor”.
Introducir Pedido de Cliente Analizar Produccion Productos

Cliente
JefeTecnico

Cursar Pedido Ordenar Fabricacion Productos

Aceptar Pedido de Cliente Planificar Produccion


JefeProduccion

Comercial

Denegar Pedido de Cliente

Diagrama de Casos de Uso “Registrar Pedido”


PLANTILLA

 Actor Principal
 Personas involucradas e Intereses
 Precondiciones
 Postcondiciones
 Escenario Principal (Flujo Básico)
 Extensiones (Flujos Alternativos)
 Requisitos especiales
 Tecnología y Lista Variaciones de datos
 Frecuencia
 Cuestiones abiertas
CASO DE USO “ORDENAR FABRICACIÓN”

 Actor Principal: Jefe Técnico


 Personal Involucrado:
 Jefe Técnico: Genera órdenes de trabajo
 Jefe Producción: Recibe órdenes de trabajo” y planifica producción
 Precondiciones:
 Es un pedido aceptado como viable
 Cada producto del pedido tiene una plantilla de fabricación
 Postcondición:
 Se han creado órdenes de trabajo
 El estado de cada orden es pendiente
 Cada orden ha sido enviada al Jefe de Producción
CASO DE USO “ORDENAR FABRICACIÓN”
 Flujo Básico:
1. Obtener siguiente producto del pedido
2. Obtener plantilla de fabricación
3. Crear orden de trabajo
4. Se registra orden de trabajo en el sistema con estado pendiente
5. Se envía orden a Jefe de Producción
 Repetir pasos anteriores para cada producto del pedido
 Flujos Alternativos: ...
 Requisitos especiales: ..
EJEMPLO: TERMINAL PUNTO DE VENTA

Realizar Venta

Cajero Cliente

Registrar Productos

Casos de Uso
Inicia
Gerente

Gestión Usuarios
Administrador
Sistema
CASO DE USO “REALIZAR VENTA”

Resumen: Un cliente llega al TPV con un conjunto de artículos. El Cajero


registra los artículos y se genera un ticket. El cliente paga en efectivo y
recoge los artículos.
Actor Principal: Cajero
Personal Involucrado e Intereses:
 Cajero: quiere entradas precisas, rápida y sin errores de pago
 Compañía: quiere registrar transacciones y satisfacer clientes.
 ...
 Precondición: El cajero se identifica y autentica
 Postcondiciones: Se registra la venta. Se calcula el impuesto.
Se actualiza contabilidad e inventario...
CASO DE USO “REALIZAR VENTA”

Flujo Básico:
1. A: El cliente llega al TPV con los artículos.
2. A: El cajero inicia una nueva venta
3. A: El cajero introduce el identificador de cada artículo.
4. S: El sistema registra la línea de venta y presenta descripción del
artículo, precio y suma parcial.
El Cajero repite los pasos 3 y 4 hasta que se indique.
5. S: El Sistema presenta el total
6. A: El Cajero le dice al Cliente el total a pagar
7. S: El Cliente paga y el sistema gestiona el pago.
8. S: El Sistema registra la venta completa y actualiza Inventario.
9. S: El Sistema presenta recibo
CASO DE USO “REALIZAR VENTA”

Extensiones (Flujos Alternativos):


3a. Identificador no válido
1. El Sistema señala el error y rechaza la entrada
3-6a. El Cliente pide eliminar un artículo de la compra
1. El Cajero introduce identificador a eliminar
2. El sistema actualiza la suma
...
7a. Pago en efectivo
1. El Cajero introduce cantidad entregada por el cliente
2. El Sistema muestra cantidad a devolver
...
....
CASO DE USO “REALIZAR VENTA”

Requisitos especiales:
- Interfaz de usuario con pantalla táctil en un monitor de pantalla plana. El
texto debe ser visible a un metro de distancia.
- Tiempo de respuesta para autorización de crédito de 30 sg. El 90% de las
veces
...
Lista de Tecnología y Variaciones de Datos:
- El identificador podría ser cualquier esquema de código UPC, EAN,..
- La entrada de información de la tarjeta se realiza mediante un lector de
tarjetas.
...
Cuestiones Pendientes:
- Explorar cuestiones de recuperación de accesos a servicios remotos
- ¿Qué adaptaciones son necesarias para diferentes negocios?
IDENTIFICACIÓN DE CASOS DE USO (LARMAN)

 “Centrarse en casos de uso de negocio


elementales: tarea realizada por una persona en
cierto lugar en cierto instante, como respuesta a
un evento del negocio que genera valor para el
negocio y deja los datos en un estado
consistente”
 Procedimiento
 Encontrar objetivos del usuario
 Definir un caso de uso para cada uno
IDENTIFICACIÓN DE CASOS DE USO (LARMAN)

 Objetivos Estrátegicos
 Ej.: Evitar pérdidas
 Objetivos de Usuario casos de uso
 Ej.: Realizar Venta
 Subfunciones ¿casos de uso?
 Ej.: Iniciar sesión (Login)
IDENTIFICACIÓN DE CASOS DE USO
(LARMAN)

 Establecer los límites del sistema


 Identificar los actores principales
 ¿Es el cliente un actor en el sistema TPV?
 Identificar sus objetivos de usuario
 Posible uso de los eventos externos
 Definir un caso de uso por objetivo de usuario
 Excepción: casos de uso para manejar información
(crear, eliminar, modificar, consultar)
DIAGRAMAS DE ESTADO DE CASOS DE
USO
introducirArticulo

Esperando crearNuevaVenta Introduciendo


Venta Articulos

finalizarVenta

EsperandoPago

realizarPagoEnEfectivo

Autorizando
Pago
realizarPagoACredito
Procesar Venta

realizarPagoConCheque
DOCUMENTOS DE ANÁLISIS REQUISITOS

 Casos de Uso
 Especificación Complementaria
 Captura otros requisitos
 Glosario
 Captura términos y definiciones
 Visión
 Define visión del producto de los stakeholders, en
términos de sus necesidades y características
ESPECIFICACIÓN COMPLEMENTARIA

 Funcionalidad
 Abarca varios casos de uso
 Ej. “Almacenar información errores”, “Cualquier uso requiere
autenticación de usuario”
 Requisitos No Funcionales (Atributos de calidad)
 Usabilidad, Mantenimiento, Adaptación, Fiabilidad, Rendimiento
 Restricciones Implementación (hardware, software, desarrollo)
 Componentes comprados y free open source
 Interfaces
 Reglas de Negocio (Ej. Reglas de descuento, Cálculo impuestos)
 Cuestiones Legales
 Cuestiones sobre el entorno físico y operacionales
 Información en dominios relacionados
VISIÓN

 Oportunidad
 Definición del problema
 Alternativas
 Descripción stakeholders
 Objetivos usuario
 Perspectiva del producto
 Beneficios del producto
 Lista de características del producto
 Coste y precio
 Otros requisitos y restricciones
MODELO CONCEPTUAL (O DOMINIO)

 Representa el vocabulario del dominio: ideas,


conceptos, objetos
 Conjunto de diagramas de clases
 No son modelos de elementos software
 Clases conceptuales
 Clases no incluyen operaciones, sólo atributos
 Atributos: números o texto
 Asociaciones entre clases
IDENTIFICAR CLASES CONCEPTUALES

 Si se hace modelado del negocio:


“Los objetos información, entrada y salida de las
actividades de los diagrama de proceso, representan
entidades y conceptos del dominio”.
 Una clase conceptual para cada información
relevante.
 De la especificación del diccionario se extraen:
 atributos, asociaciones, restricciones
 Se refina a lo largo de las iteraciones
 “Más vale que sobren clases que falten”
MODELO CONCEPTUAL: EJEMPLO

Objeto información “Pedido”


Atributos: codigo, fechaRecepcion, importe, estado,
fechaTopeEntrega
Asociaciones: Pedido-Cliente y Pedido-Producto
Restricciones: {fechaTopeEntrega > fechaRecepcion}

 También es posible identificar objetos que pasan por


varios estados (diagrama de estados preliminar)
IDENTIFICAR CLASES CONCEPTUALES

 Si no se hace modelado del negocio:


 Usar una lista de categorías de clases
 Identificar nombres de las frases
 Categorías de clases
 Objetos físicos
 Especificaciones o descripciones de cosas
 Lugares
 Transacciones
 Líneas de una transacción
IDENTIFICAR CLASES CONCEPTUALES

 Categorías de clases
 Contenedores de cosas
 Cosas en un contenedor
 Dispositivos externos al sistema
 Conceptos abstractos
 Eventos
 Procesos
 Reglas y Políticas
 Catálogos
 Contratos, documentos legales
 Instrumentos y servicios financieros
 Manuales, documentos, trabajos, libros
Modelo
Conceptual
Registra venta de

Descrita por Contiene


Catalogo Productos Producto
1 1..n
1
Usado-por Describe
0..1
0..n
0..n
Tienda Almacena 1
Item
Lineas Venta direccion
cantidad nombre 1 0..n
0..n
1..n 1
Contenidas en
1 1..n
capturada en Iniciado por
Venta TPV Gerente
1 1 1 1
1 1
1
iniciada por Registra Ventas
pagado por
1
1
1
Cliente Cajero
Pago
Producto Especial Producto Catalogado Catalogo

fabricado mediante
Producto Plantilla de Produccion

1..*

es solicitado en
base de

0..* 0..*

Pedido genera 0..* Orden de Trabajo

1..*
realizado por

Cliente

Modelo conceptual inicial


IDENTIFICAR ASOCIACIONES
 Se incluyen aquellas:
 para la que el conocimiento de la relación deba mantenerse
algún tiempo
 derivadas de la Lista de Asociaciones
 Lista de Asociaciones
 A es parte física de B
 A es parte lógica de B
 A está físicamente contenida en B
 A está lógicamente contenida en B
 A es una descripción de B
IDENTIFICAR ASOCIACIONES
 Lista de Asociaciones (continua)
 A es una línea de una transacción o informe B
 A es conocido/registrado/informado/capturado en B
 A es miembro de B
 A es una subunidad organizacional de B
 A usa o maneja a B
 A comunica con B
 A está relacionado a una transacción B
 A es el siguiente a B
 A es apropiado por B
 A es un evento relacionado con B
IDENTIFICAR ASOCIACIONES
“Encontrar clases conceptuales es más importante que
encontrar asociaciones. Se debe dedicar más tiempo a
encontrar clases conceptuales que asociaciones”

 Centrarse en las asociaciones “necesita-conocer”


 Muchas asociaciones dificultan la comprensión de los
diagramas
 Evitar asociaciones redundantes
 En la implementación se notará que falta o sobra alguna
asociación
ASOCIACIONES EN TPV
 A es parte física de B
 TPV-Caja
 A es parte lógica de B
 LineaVenta-Venta
 A está físicamente contenida en B
 Item-Tienda, TPV-Tienda
 A está lógicamente contenida en B
 EspecificacionProducto-CatalogoProductos
 A es una descripción de B
 EspecificacionProducto-Item
ASOCIACIONES EN TPV

 A es una línea de una transacción o informe B


 LineaVenta-Venta
 A es conocido/registrado/informado/capturado en B
 Venta-TPV
 A es miembro de B
 Cajero-Tienda
 A usa o maneja a B
 Cajero-TPV, Gerente-TPV
 A comunica con B
 Cliente-Cajero
 A está relacionado a una transacción B
 Cliente-Pago, Cajero-Pago
 A es el siguiente a B
 LineaVenta-LineaVenta
 A es apropiado por B
 TPV-Tienda
ATRIBUTOS

 Son valores de tipos de datos: Identidad no tiene sentido


 Tipos Primitivos: Boolean, Date, Numero, Time, String
 Tipos no primitivos: Direcciones, Colores, Número Tlfno,
Número Seguridad Social, DNI, Código de Producto
Universal, Código Postal,..
 Tipos no primitivos se deben modelar como clases si:
 Están formados por varias partes
 Son aplicables operaciones
 Tiene otros atributos
 Es una cantidad con una unidad
 No utilizar atributos como claves ajenas
PROTOTIPO INICIAL

 Utilizar los casos de uso.


 Incluye las interfaces de usuario
 Sirve para validar los requisitos: analista y
usuarios llegan a un acuerdo sobre la
funcionalidad y vocabulario.
 Prototipo desechable
 Fácil de construir con herramientas visuales.
MODELO DEL ANÁLISIS

Objetivo:
A partir de los casos de uso obtener el diseño
preliminar del sistema que deberá ser refinado
en el modelo del diseño.
 Nivel de abstracción más alto que en el diseño.
Visión ideal del sistema.
 Se define una arquitectura del sistema.
MODELO DEL ANÁLISIS

 Para cada caso de uso se define un diagrama


de secuencia del sistema que muestra los
eventos que un actor genera durante la
interacción con el sistema (caja negra)
 Cada evento da origen a una operación del
sistema
 El efecto de las operaciones se describen
mediante contratos especificados mediante
una plantilla.
MODELO DEL ANÁLISIS

 Para cada operación del sistema se define un


diagrama de interacción que muestra cómo deben
colaborar los objetos para satisfacer las
responsabilidades y postcondición expresada en el
contrato de dicha operación.

 Diseñar las colaboraciones, asignando


responsabilidades a las clases. Utilizaremos
patrones GRASP y patrones de diseño.
Cajero Realizar Venta Cliente

:Sistema
: Cajero
crearNuevaVenta
Operacion
* introducirItem(upc,cantidad)
Operacion
finalizarVenta()
Operacion
crearPago(cantidad)

CONTRATOS
Diagrama de Secuencia del Sistema
(Caso de Uso “Realizar Venta”)

:Sistema
: Cajero

1. Cliente llega al crearNuevaVenta()

TPV con
item introducirItem (CUP, cantidad)

2. Cajero inicia finalizarVenta () Operaciones


venta del sistema
3. Cajero introduce crearPago()

id item
4. Sistema registra
línea de
venta y presenta
parcial eventos del
sistema

Cajero repite pasos


3y4
CONTRATOS

 Descripción detallada del comportamiento del


sistema en términos de cambios de estado a los
objetos en el Modelo Conceptual, tras la ejecución
de una operación del sistema.
 Definición basada en pre y postcondiciones
 Las postcondiciones indican
 Creación y Eliminación de objetos
 Creación o Eliminación de asociaciones
 Modificación de atributos
CONTRATOS

 Las postcondiciones serán completas y se


descubrirán detalles en el diseño.
 Las postcondiciones nos obligarán a modificar el
modelo conceptual

¿Son redundantes los contratos con los casos de


uso?
CONTRATOS

 “Útiles cuando hay mucha complejidad y la precisión


es un valor añadido”
 “Normalmente no son necesarios, si un equipo
escribe un contrato para cada caso de uso es una
señal de unos casos de uso muy pobres o falta de
colaboración con los expertos o que les gusta
escribir documentación innecesaria”
 “En la práctica la mayoría de detalles se pueden
inferir de los casos de uso de modo obvio, aunque
obvio es un concepto muy resbaladizo”.
CONTRATOS

1. Identificar operaciones del sistema


2. Para operaciones complejas y quizá sutiles en sus
resultados, o que no están claras en el caso de
uso, construir un contrato
3. Describir postcondiciones
• Creación/Eliminación de instancias
• Creación/Eliminación de asociaciones
• Modificación de atributos
 ¡No olvidar crear asociaciones!
 Se puede usar OCL
PLANTILLA DE UN CONTRATO DE
OPERACIÓN

Nombre: signatura de la operación


Responsabilidades: qué debe hacer la operación
Tipo: clase controlador que realiza la operación
Caso de uso: nombre del caso de uso al que pertenece la operación
Notas: requisitos no funcionales
Excepciones: casos excepcionales que debe detectar
Salidas: salidas fuera del sistema, sin tener en cuenta las salidas por pantalla
Precondiciones: condiciones que han de cumplirse para realizar la operación
Postcondiciones: estado del sistema después de realizar la operación
CONTRATO “INTRODUCIRITEM”

Nombre: introducirItem (itemID: itemID, cantidad: integer)


Responsabilidades: Registrar la venta de un producto y agregarlo a la
venta. Desplegar la descripción del producto y su precio.
Tipo: Sistema
Notas: Acceso rápido a la base de datos
Excepciones: Si CUP no válido, indicar error.
Precondiciones: El sistema conoce itemID
Postcondiciones:
- Si era una nueva venta, un objeto Venta se creó y se asoció al
objeto TPV.
- Se creó una instancia lv de LineasVenta y se asoció a la venta.
- Se asignó cantidad a lv.cantidad
- lv se asoció a una EspecificaciónProducto según itemID
DIAGRAMAS DE INTERACCIÓN
 Crear estos diagramas es una actividad de AOO/DOO
muy creativo.
 Diseño de colaboraciones es la parte más difícil.
 Punto de partida para la programación.
 Crear diagramas en parejas.
 Crear diagrama de clases de análisis (DCA) en
paralelo.
Diagrama de Colaboración
2: [nuev venta] crear()

1: IntroducirProducto(cup, cant) 6: AddLineaVenta(esp, cant)


GUI : TPV : Venta

4: esp:= especificacion(cup)
7: crear(esp,cant)
3: crear()
: Catalogo 8: add(lv)
Productos

lv : Lineas
5: esp:= find(cup) Venta

: Lineas
Venta

:
Producto
DIAGRAMA DE CLASES DEL ANÁLISIS

 Se refina el modelo conceptual inicial que se


convierte en un modelo de clases del análisis.
 Se extrae comportamiento de las clases a partir
de los diagramas de interacción.
 En el diseño se refinarán los diagramas de
interacción, de modo que nuevos objetos
participarán en la interacción, y se refinará el DCA.
MODELO DEL ANÁLISIS

 Definir los subsistemas


 Para aquellas clases con objetos con
comportamiento dependiente del estado, construir
un diagrama de estados
 Dispositivos
 Controladores
 Ventana
 Transacciones
PATRONES GRASP
 “Describen los principios básicos de asignación de
responsabilidades a clases”.
 “Distribuir responsabilidades en la parte más
difícil del diseño OO. Consume la mayor parte del
tiempo”.
 Patrones GRASP: Experto, Creador, Bajo
Acoplamiento, Alta Cohesión, Controlador,
Polimorfismo, No hables con extraños
RESPONSABILIDADES

 “Contrato u obligación de una clase”.


 Dos categorías:
 Conocer
 datos encapsulados privados
 existencia de objetos conectados

 datos derivados o calculados

 Hacer
 Algo a uno mismo
 Iniciar una acción en otros objetos

 Controlar y coordinar actividades en otros objetos


RESPONSABILIDADES

 Responsabilidades “hacer” se pueden inferir de las


asociaciones y atributos del modelo conceptual.
 Puede asignarse a varias clases y métodos
dependiendo de su granularidad.
 Diagramas de interacción muestran elecciones en
la asignación de responsabilidades.
EXPERTO

¿Cómo se asignan responsabilidades?


“Asignar una responsabilidad a la clase que tiene
la información necesaria para cumplimentarla”
 Heurísticas relacionadas
 Distribuir responsabilidades de forma homogénea
 No crear clases “dios”
 Beneficios
 Se conserva encapsulación: Bajo acoplamiento
 Alta Cohesión: clases más ligeras
EJEMPLO 1

 ¿Quién es el responsable de conocer el total de una


venta?

Venta contiene LineaVenta


fecha cantidad
nota
1..1 1..*
1
Descrita por

0..*
Producto
descripcion
precio
codigo
EJEMPLO 1

¿Quién es el responsable de conocer el total de una


venta?

: Venta : LineaVenta : Producto

t:=total
* st:=subtotal
p:=getPrecio
EJEMPLO 2

: LectorCorreo :Buzon : Carpeta :Mensaje

MensajesEntre(f1,f2) mensajesEntre(f1,f2) esFecha(f1,f2)

Definir clases software a partir de las clases


conceptuales, añadiendo responsabilidades
CREADOR

¿Quién es responsable de crear una nueva


instancia de una cierta clase?

“Asignar a la clase B la responsabilidad de crear


instancias de una clase A si:
 B es una agregación de objetos de A
 B contiene objetos de A
 B registra instancias de A
 B hace un uso específico de los objetos de A
 B proporciona los datos de inicialización necesarios
para crear un objeto de A”
CREADOR

 ¿Quién debería crear una instancia de la clase


LineaVenta?

Una instancia de la clase Venta es una agregación de


instancias de la clase LineaVenta

Venta incluirá crearLineaVenta(int cantidad)

 Beneficios:
 Bajo acoplamiento
BAJO ACOPLAMIENTO

¿Cómo reducir las dependencias entre clases?

“Asignar responsabilidad de modo que se consiga


un bajo acoplamiento”
 Es un patrón evaluativo
 No considerarlo de forma independiente, sino
junto a los patrones Experto y Alta Cohesión.
 Beneficios: Facilita i) reutilización, ii)
comprensión de las clases y iii) mantenimiento
TIPOS DE DEPENDENCIAS

 Existe acoplamiento entre una clase A y otra B si:

i) A posee un atributo de tipo B


ii) A tiene un método con un parámetro, una variable
local o devuelve un valor de tipo B
iii) A es subclase directa o indirecta de B
iv) A implementa la interfaz B (Java)
EJEMPLO

:Aplicacion : TPV p: Pago :Venta


efectuarPago()
crear()

agregarPago(p)
EJEMPLO

:Aplicacion : TPV : Pago :Venta

efectuarPago
efectuarPago
crear
ALTA COHESIÓN

¿Cúanto están de relacionadas las


responsabilidades de una clase?
“ Asignar una responsabilidad de modo que la
cohesión siga siendo alta”
 Baja Cohesión: Clases con responsabilidades que
deberían haber delegado. Son “clases dios”.
Difíciles de comprender, reutilizar, mantener.
 Ejemplo anterior: En el primer caso TPV tendría
muchas operaciones, mejor delegar.
ALTA COHESIÓN

 Muy baja cohesión:


 Clase AccesoBD-RPC
 Mezcla de funcionalidad
 Baja cohesión:
 Clase AccesoBD
 Muchos métodos
 Alta cohesión:
 Clase AccesoBD + Familia de clases relacionada
 Cohesión moderada:
 Clase Empresa: conoce empleados e información
financiera
ALTA COHESIÓN

 Una clase con alta cohesión no tiene muchos


métodos, que están muy relacionados
funcionalmente, y no realiza mucho trabajo.
Colabora con otras clases.

 Beneficios
 Mejora reutilización
 Clases más claras, se comprenden mejor
 Mejora mantenimiento
CONTROLADOR

“Quién se encarga de atender los


eventos del sistema”
“Asignar responsabilidad de manejar eventos
externos a un controlador:
i) el sistema global, dispositivo o subsistema
ii) un manejador de todos los eventos de un
caso de uso
 La misma clase controlador para todos los eventos
de un mismo caso de uso.
CONTROLADOR

 Las clases de la interfaz no deben encargarse de


realizar las tareas asociadas a un evento. Deben
delegarlas a un controlador.
 Separar interfaz de la lógica de aplicación.
 Las operaciones del sistema en la capa del
dominio.
 ¿Cuándo debemos escoger un controlador de
caso de uso?
 Cuando con las otras alternativas obtenemos
controladores “saturados”
 Es posible llevar el estado del proceso actual
EJEMPLO
controlador

:AppletTPV :TPV :Venta

introItem introItem(cant,cod)
crearLineaVenta(cant,cod)

evento

Acoplamiento adecuado de la capa presentación con


la capa del dominio
EJEMPLO

:AppletTPV :Venta

introProd crearLineProd(cant,cod)

evento

Acoplamiento inadecuado de la capa presentación


con la capa del dominio
CONTROLADOR

Evento “Introducir producto”

i) TPV, ii) Tienda, iii) Cajero, iv) Manejador Compra

 Beneficios:
 Favorece la reutilización
 Posibilidad de capturar información sobre el estado del
proceso
POLIMORFISMO
¿Cómo manejar las alternativas basadas en el tipo?
¿Cómo crear componentes software conectables
(pluggable)?

Cuando las alternativas o comportamiento relacionado


varían según el tipo asigne la responsabilidad para el
comportamiento a los tipos para los que varía el
comportamiento.
POLIMORFISMO
 No realizar análisis de casos de uso basado en el
tipo de los objetos.

if tipoPago = “Cheque” then autorizarPagoCheque


else if tipoPago = “Efectivo” then autorizarPagoEfectivo
else if tipoPago = “Tarjeta” then autorizarPagoTarjeta
else if …

 Sustituir análisis de casos de uso por jerarquía de


herencia.
POLIMORFISMO

• Se añaden fácilmente las extensiones necesarias por nuevas


variaciones.
• Los clientes no son afectados por nuevas implementaciones.
• Usar si realmente el punto de variación está motivado
INDIRECCIÓN

¿Cómo evitar un acoplamiento directo entre dos


clases?

Asignar la responsabilidad a un intermediario que


crea una indirección

Ejemplo: Los adaptadores de cálculo de impuestos


VARIACIONES PROTEGIDAS (VP)
¿Cómo diseñar objetos, subsistemas y sistemas de
manera que las variaciones o inestabilidades en estos
elementos no tenga un impacto indeseable sobre
otros elementos?

Identificar los puntos de variación previstos y asignar


responsabilidades para crear una interface alrededor
de ellos
VARIACIONES PROTEGIDAS (VP)
 Ejemplo: Adaptadores de cálculo de impuestos, se
combina indirección con polimorfismo
 VP es un principio fundamental que motiva la mayoría
de mecanismos y patrones en programación y diseño
destinados a proporcionar flexibilidad y protección
frente al cambio.
VARIACIONES PROTEGIDAS (VP)
 Diseños dirigidos por datos
 Lectura de códigos, valores, nombres de ficheros,.., de una fuente
externa
 Búsqueda de servicios
 Servicios de nombres (JNDI de Java) o traders para obtener un servicio
(UDDI para servicios web)
 Diseños dirigidos por un intérprete
 Diseños reflexivos o de nivel meta
 Usar la instropección
 Acceso Uniforme
 Principio de Sustitución de Liskov
VARIACIONES PROTEGIDAS (VP)
 Diseños de ocultación de la estructura
 Principio “no hables con extraños”
 VP se aplica a puntos de variación y puntos de
evolución.
 VP es esencialmente lo mismo que los principios
“Ocultación de Información” y “Abierto-Cerrado”
NO HABLES CON EXTRAÑOS

 No enviar mensajes sobre objetos indirectos,


sino sobre la instancia actual (self), parámetros
de métodos, atributos de la instancia actual y
elementos de colecciones de la instancia actual.

class A { class B {
B at1; C at2;
void met1() { C getAt2() {return at2;}
C obj = at1.getAt2(); }
obj.met2();}
}
NO HABLES CON EXTRAÑOS

class A { class B {
B at1; C at2;
void met1(..) { C getAt2() {return at2;}
at1.met3;} void met3() {at2.met2;}
} }

class C {
void met2() {..}
}

Evitar recorrer largos caminos en la estructura de objetos


y entonces enviar un mensaje: “diseño frágil”
NO HABLES CON EXTRAÑOS

class Registro {
private Venta venta;
public void metodoFragil () {
Dinero cantidad =
venta.getPago().getCantidadEntregada()
...
}
Dinero cantidad =
} venta.geCantidadEntregadaEnPago()
MODELO DEL DISEÑO

Objetivo:
Refinar el diseño del sistema del modelo del análisis
introduciendo los requisitos no funcionales y
restricciones del entorno de implementación.

 De manera iterativa se refina el diagrama de clase del


análisis hasta obtener un diseño del sistema adecuado
para pasar a la implementación.

 Se crean los Diagramas de Clases del Diseño (DCD) que


refinan los del análisis (DCA)
CUESTIONES DEL DISEÑO

 Identificar clases (atributos y métodos) e


interfaces en el DCD
 Establecer asociaciones en el DCD.
 Establecer navegabilidad para todas las
asociaciones.
 Determinar visibilidad entre clases.
 Incluir relaciones de dependencia entre clases.
CUESTIONES DEL DISEÑO

 Definición de la arquitectura del sistema


 Subsistemas: Paquetes
 Patrones de diseño
 Estructuras de datos
 Diseño del interfaz de usuario
 Manejo de la persistencia
 Distribución
NIVELES EN UN SISTEMA DE
INFORMACIÓN
 Presentación: GUI
 Lógica de Aplicación:
 Clases del dominio del problema
 Clases servicio (acceso a BD, seguridad, ..)

 Almacenamiento
VISTA-DATOS VS.
VISTA-MODELO-DATOS

ARQUITECTURA VISTA-DATOS

 Interfaz de usuario y la lógica de acceso a los


datos son las partes esenciales de la
aplicación
 Aplicaciones “pasivas con poca lógica de
aplicación.

 No se crean clases para el modelo.


 Se pierden los beneficios de la OO
VISTA-DATOS VS.
VISTA-MODELO-DATOS

ARQUITECTURA VISTA-MODELO-DATOS

 La lógica del modelo es dominante sobre la


lógica del acceso a los datos.
 Se realiza un análisis y diseño OO completo
 Se crean clases para el modelo
 Separación del modelo de la vista
 Se favorece la reutilización y extensibilidad
VALIDACIÓN DEL SISTEMA

 Utilizar los casos de uso.


 Para cada caso de uso comprobar que el sistema
muestra el comportamiento esperado,
considerando el escenario principal y los
excepcionales o alternativos.
 Considerar requisitos no funcionales.

También podría gustarte